I am not completely sure if this is a bug, but I recently observed a LinkADRReq downlink command with "f_opts": "AzH/AAEG" which decodes to 03 31 ff 00 01 06. Command 0x03 has 1+2+1 = 4 bytes of parameters, but here we have 5. This is consistent with the outer parameters (FOptsLen iirc), but the trailing 0x06 seems to be in excess. Unfortunately it looks like that this somehow causes problems in the RN2483 LoRaWAN controller on my node (kind of buffer overflow, maybe).
Any comments?
Could 06 be another MAC command? For instance DevStatusReq?
Thank you.
You are right, if I understand the spec correctly: “A single data frame can contain any sequence of MAC commands, either piggybacked in the FOpts field […]”.
Seems the bug is in the RN2483 firmware which misbehaves whenever such a telegram is received.
Which version of the firmware is loaded on the module? And what settings at TTN are you using for the device? (LoRaWAN version, Regional Parameters version)
It’s 1.05, i.e. the latest “official”/supported release. TTN settings are LoRaWAN 1.0.2, EU868 with SF9 for RX2, RP001 Rev.B, OTAA. The error occurs with dynamic ADR mode. If I set that option to disabled, no problem occurs – which is evident because the critical downlink telegram is not generated.