Hello,
I am new to TTN and just want to add my gateway (RG191) to the network.
With TTN V2 I could use the UDP Forwarder, easy. Register the EUI and I am good.
I could use the TTN Forwarder, easy. Register the ID and copy over the API Key.
With TTN Stack V3, the I am lost. I have to:
Register the EUI
Generate the CUPS and LNS API Keys
Get a FQDN?
Spin up a linux server?
Setup the CUPS config?
Generate the CUPS Server Certificate?
Generate the CUPS Key File?
Did I miss something?
Good news, you can still use the UDP forwarder. No need to go BasicStation. And in a couple of weeks / months when the dust settles you can switch.
Do I really need to do all of that just to get Basic Station working?
I don’t know as I haven’t tried yet. However I do know TTI is working on improving documentation and instructions. So you can either solve the puzzle yourself or use UDP for now and wait until other people debugged the instructions and documentation.
I’d recommend waiting for the TTI CUPS. But if you do want to setup using LNS, it’s easy to do and described here; LoRaWAN Network Server (LNS) | The Things Stack for LoRaWAN
Do note that at the moment the LNS uses the ISRG X1 Root. We may change this since LNS certificates are supposed to be automatically handled by CUPS.
Still, I need a FQDN and spin up a server?
How does an average person that just wants to add a gateway do so?
Is Basic Station only for enterprise?
Should I just continue using UDP?
How does an average person that just wants to add a gateway do so?
Is Basic Station only for enterprise?
Nope. It’s an open protocol.
Still, I need a FQDN and spin up a server?
Why?
This doesn’t work.
LNS Server Address: wss://<server-address>:8887
wss://lns.eu.thethings.network:8887
This is the Let’s Encrypt cert.
$ export LNS_KEY="your-lns-api-key"
$ echo "Authorization: Bearer $LNS_KEY" | perl -p -e 's/\r\n|\n|\r/\r\n/g' > lns.key
wss://lns.eu.thethings.network:8887
This is not the right end point for TTN V3. Try this
wss://eu1.cloud.thethings.network:8887
Thank you. Is this documented anywhere?
I am getting closer! I think this is a Laird Firmware issue?
| RG1xx296774 | lora | user.notice | Jan 28 16:02:24 | 2021-01-28 16:02:24.804 [TCE:INFO] INFOS reconnect backoff 50s (retry 5) |
|---|---|---|---|---|
| RG1xx296774 | lora | user.notice | Jan 28 16:02:24 | 2021-01-28 16:02:24.801 [AIO:DEBU] [6] WS connection shutdown… |
| RG1xx296774 | lora | user.notice | Jan 28 16:02:24 | 2021-01-28 16:02:24.794 [AIO:XDEB] [6] ws_connecting state=1 |
| RG1xx296774 | lora | user.notice | Jan 28 16:02:24 | 2021-01-28 16:02:24.791 [AIO:XDEB] [6] ws_connecting state=1 |
| RG1xx296774 | lora | user.notice | Jan 28 16:02:24 | 2021-01-28 16:02:24.659 [TCE:INFO] Connecting to INFOS: wss://eu1.cloud.thethings.network:8887 |
| RG1xx296774 | lora | user.notice | Jan 28 16:02:24 | 2021-01-28 16:02:24.658 [AIO:XDEB] [6] ws_connecting state=1 |
I update the Laird firmware to Basic Station 2.0.5. This gives more info on the error…
| RG1xx296774 | lora | user.notice | Jan 28 16:19:07 | 2021-01-28 16:19:06.518 [any:INFO] /opt/lora/basicstation/tc.trust: |
|---|---|---|---|---|
| RG1xx296774 | lora | user.notice | Jan 28 16:18:27 | 2021-01-28 16:18:26.516 [TCE:INFO] INFOS reconnect backoff 40s (retry 4) |
| RG1xx296774 | lora | user.notice | Jan 28 16:18:27 | 2021-01-28 16:18:26.515 [AIO:DEBU] [3] WS connection shutdown… |
| RG1xx296774 | lora | user.notice | Jan 28 16:18:27 | 2021-01-28 16:18:26.515 [AIO:INFO] TLS server certificate verification failed: The certificate is not correctly signed by the trusted CA |
| RG1xx296774 | lora | user.notice | Jan 28 16:18:27 | 2021-01-28 16:18:26.507 [AIO:XDEB] [3] ws_connecting state=1 |
| RG1xx296774 | lora | user.notice | Jan 28 16:18:27 | 2021-01-28 16:18:26.374 [TCE:INFO] Connecting to INFOS: wss://eu1.cloud.thethings.network:8887 |
| RG1xx296774 | lora | user.notice | Jan 28 16:18:27 | 2021-01-28 16:18:26.373 [AIO:XDEB] [3] ws_connecting state=1 |
What CA certificate are you using?
🤦
The Laird docs said to use the lets-encrypt-x3-cross-signed.
The ISRG Root X1 cert works!
Now all forwards are dropped.
Drop uplink message - Host cluster failed to handle message: No device matches uplink
I am guessing this is an issue on the node side. Not my node, I am just hosting a gateway.
The node it not setup for V3? I thought Packet broker was supposed to support V2 and V3…
That’s informational. It just means there is no node with matching address (and keys) registered in the backend. Might well be traffic from a node on V2, a private network or a commercial network.
Addresses starting with 00 / 01 are usually private networks.
I also have randomly “drop uplink message” with the gateway Laird RG186 registered on V3 (before was on V2) + 1 node (also before was one V2, but deleted it).
But I get also “failed to schedule downlink” (becasuse gateway not connected).
Drop:
{
“name”: “gs.up.drop”,
“time”: “2021-01-29T15:06:00.088364786Z”,
“identifiers”: [
{
“gateway_ids”: {
“gateway_id”: “blu-gtw-001”,
“eui”: “C0EE40FFFF293BEE”
}
}
],
“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.ErrorDetails”,
“namespace”: “pkg/gatewayserver”,
“name”: “host_handle”,
“message_format”: “host {host} failed to handle message”,
“attributes”: {
“host”: “cluster”
},
“cause”: {
“namespace”: “pkg/networkserver”,
“name”: “device_not_found”,
“message_format”: “device not found”,
“correlation_id”: “dff74197a6bd4465896543457a340462”,
“code”: 5
},
“code”: 5
},
“correlation_ids”: [
“gs:conn:01EX79JY7G7MY03J4WN3K0BCFV”,
“gs:up:host:01EX79JY7V5FHWG8WKVJGNXYCX”,
“gs:uplink:01EX7AVY0MRYV0FTFQ5TBX7666”
],
“origin”: “ip-10-100-7-135.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_GATEWAY_TRAFFIC_READ”
]
},
“unique_id”: “01EX7AVY0R2F2HKVPZTZX2MT2F”
}
#########################################
Failed to schedule downlink:
{
“name”: “ns.down.data.schedule.fail”,
“time”: “2021-01-29T15:02:08.307504705Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “mkr-wan-001”,
“application_ids”: {
“application_id”: “mkr-wan-13xx”
},
“dev_eui”: “A8610A3039426705”,
“join_eui”: “0000000000000000”,
“dev_addr”: “260B725C”
}
}
],
“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.ErrorDetails”,
“namespace”: “pkg/gatewayserver”,
“name”: “schedule”,
“message_format”: “failed to schedule”,
“correlation_id”: “4e044e4ca07d488d8e41e52daaef695f”,
“code”: 10,
“details”: [
{
“@type”: “type.googleapis.com/ttn.lorawan.v3.ScheduleDownlinkErrorDetails”,
“path_errors”: [
{
“namespace”: “pkg/gatewayserver”,
“name”: “not_connected”,
“message_format”: “gateway {gateway_uid} not connected”,
“attributes”: {
“gateway_uid”: “blu-gtw-001@ttn”
},
“code”: 5
}
]
}
]
},
“correlation_ids”: [
“as:downlink:01EX79HVQ3M5CXQEQW0D7C65M3”,
“gs:conn:01EX79JY7G7MY03J4WN3K0BCFV”,
“gs:up:host:01EX79JY7V5FHWG8WKVJGNXYCX”,
“gs:uplink:01EX7AMV8EN02YGYTMR1NB1KSC”,
“ns:downlink:01EX7AMVNJ1JAD2YQVFGJ98FNJ”,
“ns:uplink:01EX7AMV8HJZ7D2JRWBDNEN2G9”,
“rpc:/ttn.lorawan.v3.AppAs/DownlinkQueueReplace:a8c1c3c7-349f-4d11-a97f-161faebfc197”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01EX7AMV8GKVNXCVD5B99FTC5G”
],
“origin”: “ip-10-100-14-196.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
FYI, I did get it working. I posted the how to here.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.