Devices reject ChMask in LinkADRAns

This is a bug report for the Australia TTN public cluster.

What do you want to do? Get Netvox end devices working again

What went wrong or what is missing?

Since the deployment of V2.10.3 on the AU public instance we have been seeing issues with a particular brand of sensor, Netvox, on the AS923 band plan. In particular we have been testing with a Netvox R712 Temperature/Humidity sensor.

Do you have Screenshots? Here are the steps we used to observe this issue:

The device sends an OTAA join-request
The NS responds with a join-accept, which includes a 5 channel CFList
The NS sends a LinkADRreq MAC command. The LinkADRReq contains a DataRate, TXPower and ChMask. The CHMask is set to 0xFF00 - ie, enable the first 8 channels.
The device responds with a LinkADRAns. It sets the Status bits to 1 for DataRate and TXPower, however the ChMask bit is set to 0. This indicates (according to the LoRaWAN 1.0.2 spec) that “The channel mask sent enables a yet undefined channel or the channel mask required all channels to be disabled. The command was discarded and the enddevice state was not changed."

I suspect the reason for the failure is that this device has 7 active channels (2 join+5 via join-accept), but an 8 channel ChMask via LinkADRReq. I have no ability to test whether this is actually the issue, however It’s relevant to note that a number of these devices in the field have stopped working at the time 2.10.3 was deployed. These devices were working for many months/years beforehand.

What kind of OS/Browser/Gateway are you using? Which version?

Primarily Multitech Conduit gateways using LoRa Packet Forwarder, but public network so any gateway could be involved

What are the IDs and EUIs of your Device/Gateway? (if applicable)

All app/device info/keys keys added to TTS-1118.

What do your log files look like?

Physical payloads from gateway traffic page on console Join accept: 2054C6826AE562A8DB43ADF54BAF8A06401396A994D93E22FFDAF6107DF79637B1 1st uplink: 40322A002680000006418BA2DD61144138431FBAF2FC06D2 (Device reports software/hardware version) 1st downlink: 60322A00268500000340FF00019D808003 (FOpts = 0340FF0001) 2nd uplink: 40322A0026800100003DA5EDA23FD5 (FRMPayload = 0306. ie NAck ChMask) 2nd downlink: 60322A00268501000340FF0001CAD1DBA5 (FOpts = 0340FF0001 again)

The cycle then repeats and the device never starts sending its regular payload (Temperature/Humidity)

What should happen?

The device should respond with FRMPayload = 0307, therefore not rejecting the ChMask. The device will then enter its normal mode of operation.

Can you fix this yourself and submit a pull request?

Unfortunately not.

TheThingsArchive / ttn

Devices reject ChMask in LinkADRAns #772