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

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) –

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.

@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

I’ve upgraded one of my gateways to firmware gatwick-laird- 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://

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.

Will take a look and compare my config.

I fully agree that remote ones are safer left on the Semtech UDP forwarder, they will absolutely reboot and while recent upgrades didn’t zero out my config I have had it happen…

That’s a later firmware than I just upgraded to (, must be new. Still, shouldn’t be an issue.

LNS server is correct.

The app note got changed to printf "Authorization: Bearer NNSXS.xxxxx\n">tc.key but I still think that’s wrong.

That should be {CR} or \r or ASCII DECIMAL 13 or HEX 0D. I’ve hexdump’d my tc2.key file and it definitely ends in 0d 0a

There was an error in the log somewhere about this when I had the wrong line ending. Of course I can’t remember it though, sorry.

So I’d try making a tc3.key file (to avoid any latent filename bug, but that’s possibly fixed) and try again?

1 Like

Thanks, the CrLf (0x0d, 0x0a) got it working.

My WORKING settings are now;
LNS Server: wss://
Server Certificate File: isrgrootx1.pem (from
Key File: As per app note, with windows line ending (0x0D,0x0A)

Can also confirm that the upgrade from → will result in a factory reset, but is safe to do remotely provided the gateway is able to get settings via DHCP, or you are able to remotely access the default IP if DHCP is not available


Laird has put new firmware online (GA6,, and a manual for connecting to TTN v3.
I skipped the CUPS configuration part of the manual, and now the GW is connected to TTN (hurraay!)

Latest Firmware (as of 6 Juli 2021), see

The manual from Laird, that helped me with connecting the RG1xx GW to TTN (EU), see

I used the ISRG Root X1 certificate for the LNS server, see

And I made sure that the LNS key file (tc.key) contains ONE line only, and ends with CRLF using notepad++.

Disclaimer: I did not connect any LoraWAN devices yet.

Next step: try out CUPS… ehm maybe. It looks complicated, and the GW is already working.
Whats the ‘what’s in it for me’ for using CUPS?. What does it do with regards to “Make it easier …”?

Great that it’s working!

In the short term, CUPS won’t improve your experience. CUPS allows remote reconfiguration, so the gateway first connects to a CUPS server, from which it retrieves an LNS address and credentials. In the future, this will allow you to point all of your gateways to a new network server remotely, just by updating the CUPS server.

If you do want to try it, the complex instructions for configuring CUPS here are now outdated → Application Note - Setting up Basic station on the Things Stack v3 | Laird Connectivity

We’ve added a feature in the Console to allow you to configure an LNS API key → Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN. Previously, this was only possible to do via the command line, which is why the Laird CUPS instructions have a long section about installing the CLI. You should be able to configure CUPS using just the instructions here → Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN.

1 Like

@benolayinka Thanks! Keep up the great work!

I have now configured two new Laird RG1xx (868) gateways’s using Basics Station and using CUPS only. Works like a charm. The LNS address and other settings are automatically retrieved after configuring CUPS.

Some remark: For CUPS to work, you have to make sure that the “LNS Server” field in the “LoRa” tab of the RG1xx configuration console is emptied. Steps I took:

  1. Configure CUPS (add server address, certificate and key file as mentioned in the earlier posts.
  2. empty the LNS server field in the (web) config panel of the RG1xx
    Then and only then the GW started to retrieve the LNS info using CUPS.

Configuring LNS settings, like LNS server, certificate and LNS key file is not needed in this case (maybe even unwanted?)

Additional Question. Just to be sure:
Is setting the LNS certificates (Server certificate file and key file) on the Laird RG1xx Gateway unneeded/unwanted when using CUPS to retrieve the LNS info?

In other words: configuring CUPS on the GW is enough to get everything running/transmitting/forwarding?

I can see that the GW is connected to TTN, in the TTN console. However, I did not check with a device yet to send data via the GW (if the data chooses to go that way ;-))

Yes, exactly. No need to configure LNS if CUPS is configured. Most gateways just ignore the LNS settings when CUPS is configured, but on some it can cause conflicts, so best to leave everything empty.

1 Like