Can't get Laird RG1xx Basics Station Forwarder working with TTN

Gateways
5

I’m very interested what Laird has to say about this. Please keep me posted.

6

@benolayinka could we please get more information on how you setup the Laird RG1xx in your recent video with Basic Station?

https://youtu.be/h_6dIte_IxI?t=313

Thank you!

7

I don’t think the video is meant for explaining the configuration of Basics Station on the RG1xx. Its just a general review of several available LoraWAN gateways, which shows also the configuration (web) interface for each gateway.

Very confusing in the video is the ‘show the configuration’ part, which shows a configuration being entered for a CUPS server. While actually you should be configuring an LNS server according to the documenation of Laird, see Application Note - Setting Up Basics Station on TTN | Laird Connectivity.

Allas… both dont work for me… So I’m still looking for a solution.

8

Hello @jakymiwm and @jvbelle ! We have instructions in our documentation for connecting the RG1xx with Basic Station → Laird Sentrius™ RG1xx LoRaWAN Gateway | The Things Stack for LoRaWAN

You should be using CUPS, as CUPS automatically configures LNS and allows for any future credentials updates to be propagated automatically to your gateway.

To configure CUPS, you also need to use the CLI to provide the Stack with your LNS key, so it can send that to the gateway when it connects. We’re working to simplify this process, but for now the instructions are all in the CUPS documentation → Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN

You’ll also need to use the DST Root X3 certificate as this gateway doesn’t support concatenated .pem files → Root Certificates | The Things Stack for LoRaWAN

EDIT: Sorry, I didn’t see that you were trying to connect to The Things Network V2. You should indeed use LNS, with the DST Root X3 certificate.

We also recommend that you upgrade to The Things Network V3, which we just released at the conference. Your existing login credentials should already be migrated, login using The Things ID and your existing username and password → https://eu1.cloud.thethings.network/

9

Keep in mind your applications need migration to V3 as well if you migrate the gateway to V3.

10

Hi, Thanks for replying. I was just typing… I’m indeed using TTN (and not TTI), thus via https://www.thethingsnetwork.org/ . And for configuration my gateways on the TTN side I use https://console.thethingsnetwork.org/gateways. These still use the V2 version of the stack, like you state at the end of the message :wink:

I also see your statement regarding upgrading to the TTN V3 stack, I’ll try that using the documentation at: The Things Network upgrade to V3

(and of course watch the opening keynote :))

I hope the documentation on TTN will also be updated soon (which I can understand takes a while on the community driven TTN)

Thanks! I’ll let you the results after taking some time for adapting to the changes.

11

Mmm I’m now in the ‘forest’ of documentation that should lead me to a working Gateway.

At Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN, chapter " Configure CUPS to Send the LNS API Key" it is pointed out that I should use the command line interface of TTN V3 to “We need to configure CUPS in The Things Stack to transmit the LNS API key when a gateway connects…” Why is this not supported in the web interface? For ‘normal’ users it takes a lot of hassle to get things done in this way… Still want to be a happy user ofcourse, But the documentation in this form is way to difficult for average users who just want to add there gateway to the community network. If we want to build a community network, things should be simpler imho.

btw the documentation at Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN uses steps that can be only completed fom a linux command line, like:

$ export GTW_ID="your-gateway-id"
$ export LNS_KEY="your-lns-api-key"
$ export SECRET=$(echo -n $LNS_KEY | xxd -ps -u -c 8192)
$ ttn-lw-cli gateways update $GTW_ID --lbs-lns-secret.value $SECRET

The export command does not exist in windows. Nor does the xxd command that is uses after the pipe.
So im trying in my mingw environment now… (for average users… not very doable).

I’m getting error: error:cmd/ttn-lw-cli/commands:unauthenticated (not authenticated with either API key or OAuth access token)
at this step.

So i tried “$ttn-lw-cli.exe login” (both in mingw as in windows cmd shell) to log in/get the oath token. my browser opened when running the command but it cant connect to the said url at localhost.
Thus I’m stuck at the moment.

In the ‘old’ situation (TTN) I could manage everything from the web UI of the TTN console. Which was much more user friendly.

3 Likes
12

Hello @benolayinka, you mentioned one should

[…] use the DST Root X3 certificate as this gateway doesn’t support concatenated .pem files

But that works for a custom deployment of the stack right? How to connect the gateway to TTS v3 Cloud (community)?

I tested even extracting the The Things Industries Root CA from ca.pem but it doesn’t seem to work. Maybe I’m missing something ?

13

I need a FQDN and a server running The Things Stack?

I just want to add my Laird to the network.

14

I am trying the same, but on a Linux machine.

I configured manually the .ttn-lw-cli.yml file.

I had error initialli because I thought that oauth-server-address was using port 8887, but instead is on 443.

configuration file:
oauth-server-address: ‘https://eu1.cloud.thethings.network/oauth’
identity-server-grpc-address: ‘eu1.cloud.thethings.network:8884’
gateway-server-grpc-address: ‘eu1.cloud.thethings.network:8884’
network-server-grpc-address: ‘eu1.cloud.thethings.network:8884’
application-server-grpc-address: ‘eu1.cloud.thethings.network:8884’
join-server-grpc-address: ‘eu1.cloud.thethings.network:8884’
device-claiming-server-grpc-address: ‘eu1.cloud.thethings.network:8884’
device-template-converter-grpc-address: ‘eu1.cloud.thethings.network:8884’
qr-code-generator-grpc-address: ‘eu1.cloud.thethings.network:8884’

One has to login before command
ttn-lw-cli gateways update $GTW_ID --lbs-lns-secret.value $SECRET"
I opened manually the browser with address on terminal since it didn’t arrive to open.
I got the json answer with lbs_lns_secret key_id f.

Had yet to finish, since have other things to do now.

1 Like
15

Hello!

I think I got it working. I am still having this issue below:

Drop uplink message - Host cluster failed to handle message: No device matches uplink

Try this!

Add the Gateway to the console:

Per: https://www.thethingsindustries.com/docs/gateways/concepts/adding-gateways/

Console: The Things Network Console

Create CUPS API key for your gateway with the following rights:

  • View gateway information

  • Edit basic gateway settings

  • Retrieve secrets associated with a gateway

Create LNS API Key with the following rights:

  • Link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink

Create the CUPS Key (I did this on a Raspberry Pi)

$ export CUPS_KEY="your-cups-api-key"
$ echo "Authorization: Bearer $CUPS_KEY" | perl -p -e 's/\r\n|\n|\r/\r\n/g'  > cups.key

Create the LNS Key

$ 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

Setup Laird (I am using 93.8.5.25, I think 93.8.5.21 would work as well.)

Semtech Basic Station

CUPS Server Address:

LNS Server Address:

  • wss://eu1.cloud.thethings.network:8887

CUPS and LNS Server Cert:

CUPS Key

  • Generated above

LNS Key

  • Generated above
3 Likes
16

Thanks! I did something like this before, going to see where i did different.

17

Yep, you are 100% right, and we are adding this as soon as we can.

ttn-lw-cli login shouldn’t connect to localhost - you need to configure it to use TTN v3. Do ttn-lw-cli use eu1.cloud.thethings.network → https://www.thethingsindustries.com/docs/the-things-stack/interact/cli/installing-cli/

Once you’ve got that, you’ll be able to use it to add the LNS key. Again, really sorry that this is still a CLI only command, we’re building this in to the console now.

2 Likes
18

Your gateway is working! This means that it received a packet for a device that is not registered in TTN or your own deployment.

1 Like
19

Thanks @benolayinka for the tips, I’ve got my RG191 across from v2 to v3 (in AU) with basic station forwarding - the instructions above with CUPS were helpful for me. Its mostly working, although I note a few issues on device joins via this gateway using v3 stack which I did not have when I was using v2 - a little unreliable and takes my device a few attempts to join the network, so I need to troubleshoot this issue separately. But I don’t intend to go back to v2 given it will become read-only shortly.
Just a hint to those having issues with not having linux. I installed the windows binaries for the CLI support and then used GIT BASH shell to give me xxd etc. It worked well, hope this information helps someone else trying to get their gateway going with CUPS.

1 Like
20

It’s possible to get it working only using LNS, which is easier if maybe a little less stable in the O(5 years) timeframe.

I followed the instructions in the Laird App Note here. There’s a bug in the instructions though, and then another bug which compounds it:

It says

For Unix based OS - “\r” must be added to end of key for proper line endings

but then gives the command
Echo -e "Authorization: Bearer NNSXS.xxxxx\n">tc.key

Which is wrong. Do what it says, not what it did. The correct command is:
echo -e "Authorization: Bearer NNSXS.xxxxx\r">tc.key

The second bug is that if you upload a key file with the same name it doesn’t seem to stick – rename it to tc2.key and upload it and it’ll be fine. And it’ll go to the configured band plan and not the one hardcoded on the device (important for RG191s sold into other countries prior to this hard-setting and country-specific versioning).

If you do this key file incorrectly there is an error in the log (bottom lines, turn on auto-updating) saying the key file is in the wrong format but it wasn’t updating the first time I uploaded everything (and in fact locked itself into online state but didn’t do anything). Rebooting helped.

21

For anyone else finding this forum post.
I’ve managed to get a Laird RG191 working on the TTNv3 using the semtech forwarder.
In my case I am using AU915 bandplan and the gateway won’t let me as it seems to stay forced in region “US” when manually configured. The trick is that you have to download the LoRa config (json file), modify the frequencies and then reupload the config. The web config will stil complain about the incorrect radio frequencies, but it does work.

If you need further detail, or the JSON file, It’s on my blog at Laird RG191 gateway on TTNv3 (AU915) – john.geek.nz

22

Thanks John, that’s really interesting and useful. I still can’t get the config backup to work (I get a validation error) and I’ve never raised a ticket to find out why. Possibly it doesn’t like my LAN/Wifi config.

Out of interest why are you persisting with the Semtech forwarder? It’s definitely workable to get a RG191 US working on AU915 with the Basics Station on TTS CE (v3), and it auto-configures based on the TTS bandplan (despite the web restriction) which is nice.

23

@bwooce I’m only using the semtech forwarder as I was finding a lack of documentation how to get them working any other way.
Would be great if you have step by step docs on how to do it - I only have 5x RG191 gateways so don’t want to have to spend too much time getting them working. Most of my gateways are all MikroTik now

25

I’ve upgraded one of my gateways to firmware gatwick-laird-93.9.6.12 and following the instructions in the Laird App Note, taking note of the two bugs with the EOL and filename for the key, but having issues.

I’ve set the lns server to wss://au1.cloud.thethings.network:8887

For the LNS Server Certificate File I’m using isrgrootx1.pem, but have also tried cacert.pem and The-Things-Stack-cert_ca_minnimal_no-comment.pem.

My key file is named tc2.key and contains:
Authorization: Bearer NNSXS.MYAPIKEY{LF}
Where {LF} is a line feed (ASCII DECIMAL 10 or HEX 0A)

It’s not connecting to TTN v3 though.
The logging doesn’t show much - sighnature verification failed in weblcm and other than that reconnect backoffs getting bigger and bigger.