Join requests received are considered as unexpected

[adcoly]

Expected Behavior

I install two different gateways on the same Network.
The first one (lbs version 2.0.5) handle properly each device we work with.
The second has a different version of LBS (2.0.6) should also work (same configurations, same deployment).

Current Behavior

Join Requests handled by the second gateway are considered as "unexpected" by the LNS.

Context (Environment)

Device (Host) Operating System

Ubuntu 20.04

Architecture

x64

Container Operating System

Linux Containers

LoRaWAN Module Version

2.2.1

Docker

20.10.25+azure-2

Logs

We notice an additional parameter in the Join Request from the 2nd Gateway: "fts"
Here is a join request from the operational Gateway:

<GatewayID> Received 'jreq' message: '{"msgtype":"jreq","MHdr":0,"JoinEui":"<JoinEUI>","DevEui":"<DevEUI>","DevNonce":18307,"MIC":1914631336,"RefTime":0.000000,"DR":5,"Freq":470700000,"upinfo":{"rctx":0,"xtime":25332748023622995,"gpstime":0,"rssi":-40,"snr":9.5,"rxtime":1704768074.358533}}'.

Here a "failing" join request from the 2nd Gateway:

<GatewayID> Received 'jreq' message: '{"msgtype":"jreq","MHdr":0,"JoinEui":"<JoinEUI>","DevEui":"<DevEUI>","DevNonce":3020,"MIC":1613391280,"RefTime":0.000000,"DR":5,"Freq":470500000,"upinfo":{"rctx":0,"xtime":1050702827,"gpstime":0,"fts":-1,"rssi":-102,"snr":1.75,"rxtime":1704848901.805680}}'.
<GatewayID> Received unexpected 'jreq' message: {"msgtype":"jreq","MHdr":0,"JoinEui":"<JoinEUI>","DevEui":"<DevEUI>","DevNonce":3020,"MIC":1613391280,"RefTime":0.000000,"DR":5,"Freq":470500000,"upinfo":{"rctx":0,"xtime":1050702827,"gpstime":0,"fts":-1,"rssi":-102,"snr":1.75,"rxtime":1704848901.805680}}.

[Mandur]

Hello @adcoly

As discussed via chat I tried to replicate the situation via a test. Turn out we also support this fts settings cf here : https://github.com/Azure/iotedge-lorawan-starterkit/blob/72453e031f642e46b6d518c169e97d4ec9e91d73/Tests/Unit/NetworkServer/JsonHandlers/LnsDataTests.cs#L131C36-L131C36 So this can be our issue.

My hypothesis is that some of the other settings are wrong. Could you please send me via IM a complete payload so I could try deeper troubleshooting...

[adcoly]

Hello @Mandur !

After few research on our side, we might have noticed something that could explain the behavior we have with those Chinese Gateways.

In our "routerConfig" for those Gateway, the parameter "region" is set to "CN470". This region name might not be recognize by the LNS (it must only recognize "CN470RP1" or "CN470RP2"), and lead to this "unexpected" issue.
But if we change the "region" parameter to "CN470RP2", the gateway does not recognize the region name and will then refuse every message received from the LNS, saying it has no "routerConfig".

Would it be possible to have something as the following screenshot to allow the region name to be "CN470" on the Gateway side, but keeping the "CN470RP1/2" on the LNS side ?

(We wanted to do the test locally to change this part of the code and try on our Chinese site but we did not manage to get this time)

[Mandur]

Good catch @adcoly we will be providing a hotfix shortly so you can test it and integrate the fix in the next release

[adcoly]

Thank you for the hotfix. It has been deployed and will be tested in the incoming days. I'll keep you up to date on how the test goes :)