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
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)
Downgrading firmware version
to
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
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)
I’ll be very interested in your results @jvbelle , I only have one and it’s my home (dev) gateway so I’m less inclined to experiment with it (I have enough yaks to shave as it is).
Good luck!
No luck over here. Its been a really bad experience using the Laird/TTN combo with basics station. First off, the upgrades/downgrades are really a pain to do correctly. Second, configuring the gateway is also not very convienent using the web config tool of the gateway. Logging is very limited in the UI.
I have tried the most recent tutorial from laird:
https://www.lairdconnect.com/documentation/application-note-setting-basics-station-ttn
But with no success. I cant get my Laird RG186 gateway connected to TTN by using basic station.
Does anybody have tips for me?
One concern of my: does ws port 443 go through my firewall?
That’s disappointing. You turned on the logging on the bottom bar, and dragged it open and said update automatically? The other logging is…terrible (the persistent logging with the same date/time is just annoying, is that fixed yet?)
Maybe paste a link to the log here (gist/pastebin)? I don’t think there’s anything secret in them, but have a look first 
From the log
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | 2021-01-13 20:26:21.583 [TCE:INFO] INFOS reconnect backoff 10s (retry 1) |
|---|---|---|---|---|
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | 2021-01-13 20:26:21.582 [AIO:DEBU] [5] WS connection shutdown… |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | 2021-01-13 20:26:21.567 [AIO:XDEB] [5] ws_connecting state=1 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | 2021-01-13 20:26:21.540 [TCE:INFO] Connecting to INFOS: wss://lns.eu.thethings.network:443 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | 2021-01-13 20:26:21.539 [AIO:XDEB] [5] ws_connecting state=1 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | key usage : Digital Signature, Key Cert Sign, |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | basic constraints : CA=true, max_pathlen=0 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | RSA key size : 2048 bits |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | signed using : RSA with SHA-256 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | expires on : 2021-03-17 16:40:46 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | issued on : 2016-03-17 16:40:46 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | subject name : C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3 |
| RG1xx297A94 | lora | user.notice | Jan 13 20:26:21 | issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 |
That all looks fine, the right server from what we’re told, and you have a valid cert.
It’s probable the next messages will be the error/timeout. Also check if LoRa/Advanced has Logging Level set to Debug?
It keeps repeating this part over and over again (see bottom):
I cant find an option to set the Logging Level to Debug in the Gatway’s Web UI.
(I dont have remote logging, cant find a manual for that either so im using the logging from the web UI)
| RG1xx297A94 | lora | user.notice | Jan 14 08:22:24 | 2021-01-14 08:22:23.617 [TCE:INFO] INFOS reconnect backoff 60s (retry 8) |
|---|---|---|---|---|
| RG1xx297A94 | lora | user.notice | Jan 14 08:22:24 | 2021-01-14 08:22:23.616 [AIO:DEBU] [3] WS connection shutdown… |
| RG1xx297A94 | lora | user.notice | Jan 14 08:22:24 | 2021-01-14 08:22:23.608 [AIO:XDEB] [3] ws_connecting state=1 |
| RG1xx297A94 | lora | user.notice | Jan 14 08:22:24 | 2021-01-14 08:22:23.582 [TCE:INFO] Connecting to INFOS: wss://lns.eu.thethings.network:443 |
| RG1xx297A94 | lora | user.notice | Jan 14 08:22:24 | 2021-01-14 08:22:23.581 [AIO:XDEB] [3] ws_connecting state=1 |
What cert are you using?
Currently, their FW update URL is
https://connectivity-firmware.s3.amazonaws.com/rg1xx-lora-gateway/firmware/newest/fw.txt