Hi all,
Does anyone know the firmware update URL for a Laird RG1xx gateway?
I’ve searched through their support forum but can only find the tarball download, and not a link.
Thanks.
FYI, I finally sniffed this out of 48 hours of researching 
I found the update link in this pdf.
The URL is https://www.lairdtech.com/products/rg1xx-lora-gateway/firmware/latest/fw.txt
1 Like
Hi,
I did the same thing this morning, I found the firmware 93.7.3.4 on this adress:
https://www.lairdtech.com/products/rg1xx-lora-gateway/firmware/newest/fw.txt
have a good day
It actually depends on current firmware version of the gateway which update link to use.
Which link to use, in the Sentrius RG1xx WebLCM, is written down in the user guide.
Not using the correct link results in reset to factory defaults.
New firmware gatwick-laird-93.8.4.28 released, if anyone didn’t notice.
- Added support for operating in Hong Kong, Taiwan, Australia, and New Zealand on the RG-191
- Added regulatory limits for all supported regions
- In most cases, updating firmware should no longer require a factory reset
- Added remote management via TR-069 (an externally hosted ACS server is required to use this feature)
- Updated the loraserver.io bridge to version 3.0.1(supports the v3 server)
- Updated the Senet packet forwarder to a more recent version
- Removed the Loriot packet forwarder
New firmware again 93.8.5.18, with the slightly cryptic (emphasis added) removal of the TTN forwarder? Also don’t hit the upgrade button if you’re using it (and if you’re here…you probably are) as it’ll brick the LoRa config page. But don’t worry they mention this in the release notes, so it’s fin (/sarcasm).
- Added support for operating in Malaysia and Singapore on the RG-191.
- Added Semtech Basic Station as a forwarder option.
- Removed TTN as a forwarder option. TTN is discontinuing support for this forwarder.
- Removed MQTT as a forwarder option.
- Updated the Senet packet forwarder to a more recent version which also includes the Senet RAN mode of operation.
- Updated the TR-069 parameters to reflect the updated packet forwarder options.
Isn’t this a regression if we have to go back to the UDP Semtech forwarder?
1 Like
Wow, so they want you to factory-reset the thing before upgrading, emphasis mine:
A couple of packet forwarders are no longer supported in this release. If a unit on a previous release, with any forwarder set as the active packet forwarder that is no longer supported, and is upgraded to this release, the LoRa section of the UI is non-functional. The workaround is to factory reset the device or set the packet forwarder to the semtech legacy UDP packet forwarder through the web interface, before upgrading the firmware. Factory resetting reverts the gateway to use the legacy Semtech packet forwarder by default, which re-enables the disabled LoRa section of the UI.
No, they want you to switch to the semtech forwarder before upgrading.
No it is not because you can use Basic Station which is a step forward from the discontinued TTN forwarder.
1 Like
Very true. I intended to emphasise the “before” part, but failed. Anyway, in Slack someone seemed to be stuck, but wrote a few minutes later:
Albert Ong 23 minutes ago
I saw that and tried a factory reset, and yeah, still have the issue.
…
Albert Ong 16 minutes ago
Ok, lol, tried it again. Seems to have worked lol.
Many of my early deployments used legacy PF, but as list grew having a Dev ID set as EUI-‘Random Gobbledygook’ (ok MAC derived but looks rubbish in a long list 
) wasnt easy to review & manage and so have moved to Jac’s MP PF where I can (e.g. Pi builds) or used others for later Laird deployments as could have useful names like ‘gs3-ttn-testGW031’!
Does change mean updates will force fall back to dumb e.g. eui-c0ee40ffff293c43 - will we need to re-register on TTN as no option on console to change the as registered PF, cleaning up long GW list on tTTN Console then means deleting GW…which means ID cant then be re-used etc. 
Questions, Questions… I know TTN PF now abondonware but if aint broke dont fix it surely! Removal forces hard choices such as cant use any security or performance/function fixes etc. bundled in new f/w unless willing to change PF?
For now it does. TTN community network ‘forces’ you to register gateways with BS (how’s that for a shortened PF name) using the EUI for now (V2). This might change when the community network switches to V3.
I will forgo updating my Laird gateway to remove the need to re-register the gateway using EUI now and may be yet another mechanism later on.
Thinking the same! 
Pity is I have one old (solar powered) Laird GW that has been offline for a time and was looking to perhaps reflash firmware to try & recover LoRa module connectivity (remote diagnostics shows main board working, connects over WiFi & Wireline Enet, but no longer responsive to LoRa module status/config) in coming months (on a mast with limited, long time delay access - need to roll out scaffolding on difficult to access site) 
) so may just roll forward to an earlier release that still has the TTN Forwarder…
Ouch, the new firmware (93.8.5.18) removed the TTN forwarder. Now, on my new gateways (Laird RG186), I have to use the Legacy Semtech forwarder (which I don’t want to use). Or I have to use the latest and greatest Semtech Basics Station forwarder (which is badly documented at the TTN website).
How do you configure the Semtech Basics Station forwarder for TTN with the Laird RG186?
At the TTN side: the TTN Console for registering gateways (https://console.thethingsnetwork.org/gateways/register) only provides a configuration page for the Legacy semtech forwarder and the now discontinued TTN forwarder… There’s no page for registering a gateway with a Semtech Basics Station forwarder.
At the Laird RG186 side: TTN does not provide info on how to configure the Laird RG186 gateway wrt the Semtech Basics Station forwarder (e.g values for CUPS bootserver, CUPS Server, LNS server, … etc)
So… im a bit stuck now… How do I use the Basics Station Forwarder to connect my RG186 gateway to the TTN network?
Check the legacy forwarder box… this is the same situation as the TTIG which also uses the BS PF…there is then bridging s/w in TTN backend which brings the data into the system but it looks like classic legacy UDP handler traffic
1 Like
I’ll try it next week when I have access to the gateway.
I am not having a good time and have an expensive paperweight right now. Note that I’m in AU915 with a gateway that was bought before AU915 was a Laird model.
I can’t use the Semtech UDP/Legacy forwarder as it won’t configure the gateway, and the gateway (since some recent firmware) is hard locked to the US region. I can’t set a Radio 0 centre frequency of > 914.5MHz and I’m not sure if the UDP forwarder is supposed to auto-configure from the TTN settings, but it doesn’t/is ignored.
Using the Semtech Basics Forwarder, with an LNS Server of: wss://lns.au.thethings.network:443 and the Server Cert set to the chain cert (https://letsencrypt.org/certs/trustid-x3-root.pem.txt) starts to look positive but the logs say (in reverse order):
2020-03-20 07:52:46.597 [AIO:DEBU] [6] WS connection shutdown…
2020-03-20 07:52:46.597 [AIO:ERRO] [6] WS upgrade failed with HTTP status code: 502
2020-03-20 07:52:46.596 [AIO:XDEB] [6] ws_connecting state=3
2020-03-20 07:52:46.582 [AIO:XDEB] [6] ws_connecting state=2
2020-03-20 07:52:46.581 [AIO:XDEB] [6] ws_connecting state=1
2020-03-20 07:52:46.376 [AIO:XDEB] [6] ws_connecting state=1
2020-03-20 07:52:46.359 [TCE:INFO] Connecting to INFOS: wss://lns.au.thethings.network:443
2020-03-20 07:52:46.346 [AIO:XDEB] [6] ws_connecting state=1
2020-03-20 07:52:46.248 [AIO:INFO] tc has no key+cert configured - running server auth only
I will contact support.
Right.
Downgrades are possible and supported on the RG1xx series, just put in one of the older firmware URLs (nice work on that Laird). There is a little twist that it might look like it bricked the unit as any cached part of the UI (like the .js) doesn’t get invalidated and so the Web UI doesn’t load after the downgrade (in my case, at least). Clearing the browser cache worked well…took me a week and a prompt from support to do it.
So I have a working gateway again, using the TTN Forwarder, except I can’t upgrade it. The Product Managers answer is that TTI supports Basic Station and so…well…wait for that to hit TTN (I guess) before upgrading. I’m absolutely not certain if the basic station config responses will override the hard-configured region (US915) in my gateway, as the TTN Forwarder does today. I’d hope so…
Interestingly my .au LNS address was never going to work. I’m starting to explore what the GW needs to send and what it will receive. Doing that I found that the .au LNS address resolves but isn’t a TTN v3 LNS server…it gives the 503 noted above in the Laird logs.
Querying the .eu LNS works…and I learnt something:
wscat -c "wss://lns.eu.thethings.network:443/router-info"
Connected (press CTRL+C to quit)
> { "router" : "C0:EE:40:FF:FF:29:67:EE" }
< {"router":"c0ee:40ff:ff29:67ee","muxs":"muxs-::0","uri":"wss://lns.eu.thethings.network:443/traffic/eui-C0EE40FFFF2967EE"}
Disconnected (code: 1006, reason: "")
If someone has a spare RG1xx lying around and wants to see if it actually works by configuring in that LNS address that would be very interesting. The logs should reveal interesting things even if it doesn’t work. ( you need to have configured the EUI in TTN first, as a legacy type…it’s a bit of a hack to avoid updating TTNv2)
1 Like
Downgrading firmware version
- 93.8.5.18 (March 2020 update, TTN forwarder support removed)
to
- 93.8.4.28 (October 2019, TTN Forwarder selectable)
is not possible , because Laird used the same URL for both of these firmware versions…. Ouch….
See : https://connectivity-firmware.s3.amazonaws.com/rg1xx-lora-gateway/firmware/newest/fw.txt
which contains version “Laird Linux gatwick-laird-93.8.5.18”
and https://connectivity-firmware.s3.amazonaws.com/rg1xx-lora-gateway/firmware/latest/fw.txt
which contains version “Laird Linux gatwick-laird-93.7.2.10” which is of March 2018.
So, the 2 versions that were released in between are not available any more for download….
Not a very good release management of Laird IMHO.
The release notes of all versions, can be found here: https://connectivity-staging.s3.us-east-2.amazonaws.com/2020-03/CONN-RN-RG1xx_v93_8_5_18_0.pdf
1 Like
I’d stopped bothering to look, but recently took a peek and there is now a setup guide for BasicStation on TTN which is great. Nice work Laird.
It doesn’t resolve the problem that I’m using an RG191 (the original model, for “US915”) in Australia on AU915. Since the release of an AU-specific model they’ve locked any ability to configure it out of the original region. With the best intentions of not violating licensing regs I’m sure.
This works fine under the TTN Forwarder (deprecated, removed from Laird firmwares now) because it configures the AU915 frequencies into the RG191 as part of the setup, based on the TTN config. I’m not prepared to experiment with it under BasicStation, but I’m going to assume that bit of the BasicStation functionality (CUPS?) is not going to work under TTNv2 at least.
Please let me know if you experiment with this.
Thanks for the info! I have another 2 Laird RG186 gateways that are waiting to be configured and installed. To be honest, they were just catching dust because of the lack of proper documentation of how to configure them with TTN and BasicStation (… and partly because I was really not amused by the sudden drop of TTN forwarder support by Laird in favor of BasicStation, while at the same time the BasicStation documentation at TTN and Laird was not in place yet to make an easy transformation.
The whole configuration process should be a lot easier and more user friendly. Also at the TTN side (The TTN dashboard ‘new gateway’ option still does not show BasicStation as option)