Strange behavior with linkcheckmode + ADR both enabled on TTN?

[pomplesiegel]

Is anyone else experiencing strange behavior on TTN (community / v2) when having ADR and linkcheckmode both enabled?

I'm running LMIC v3.2. I have no idea if this is a TTN or LMIC issue.

Everything else is working perfectly, but I'm finding that sometimes TTN gets stuck in an eternal port 0 downlink situation. It will just keep sending port 0 downlink messages to a device, which theoretically would be for ADR changes? However, it just keeps going on.

One way I have found to more easily reproduce this is to unplug the gateway, turn on devices with ADR + LinkCheckMode enabled, then plug in the gateway. At first the devices join, receive ADR messages, and everything seems fine, but over the next few minutes the downlink messages begin appearing AND the device for some reason will not receive intentional port 1 downlink messages I have sent from TTN. Serial logs indicate that the device's application code was not given the downlink message, even though TTN reports its as successfully sent.

Usually those messages will trigger the log:

if (LMIC.dataLen) //this means we received a downlink message 
        {
            Print("!!!RECEIVED A DOWNLINK MESSAGE!!! of length " + String(LMIC.dataLen));
...

but this does not occur.

This ringing a bell for anyone?

Environment

• Version of LMIC being used: v3.2
• Version of Arduino IDE being used: 1.8.12
• Network provider (The Things Network, Swisscom, ChirpStack, etc.): TTN
• Region (EU868, US915, etc.): US915
• Board (MCCI Catena, Adafruit Feather M0, Heltec, etc.): Adafruit Feather M0
• CPU (AVR, STM32L0, etc.)
• Radio (HopeRF, SX1276, etc.): HopeRF
• Gateway: Multitech conduit w/ FW v5

Thank you! Michael

[pomplesiegel]

One more thought: Even when it's not stuck in an eternal downlink situation, sometimes TTN still sends 7 port 0 downlink messages in a row, for a device which is totally stationary, in the same small room as the gateway. It seems very strange, as the SNR is so obviously high. This will happen quite frequently, such as after every 10 uplink messages or so.

[pomplesiegel]

Indeed 7 (and sometimes 8) are the strange magical downlink numbers (filtering only for the weirdly common downlink messages)

Other potentially relevant log info:

[pomplesiegel]

Left running over the weekend and the same situation holds:

and

[ngraziano]

The "link-adr" "intial" seems related to ConfirmedInitial set to false in https://github.com/TheThingsNetwork/ttn/blob/2e549df387021dbaf58257a770b693be622666f1/core/networkserver/adr.go#L110

This value seems to be set to true when the device ack the dowlink adr command (https://github.com/TheThingsNetwork/ttn/blob/00a6f7874bb9a7d00aab6e9740e9fc7530820015/core/networkserver/uplink_mac.go#L67)

One option is that the device did not receive the downlink packet.

So to understand why lmic do not ack the adr command we must see the raw packet receive by the device to see the FOpts field of the packet and the response from the device. The raw packet is not visible in the Application console of TTN but only in Gateway Console.

You can use https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/ to get the different fields. (no need of the keys because ADR option field is not crypted)

[pomplesiegel]

@ngraziano, Great thank you very much! I will report back with results.

Anecdotally, have you seen something like this occur recently? I am using a very generic set of hardware + use case + latest LMIC and TTN community, so I have to imagine others are experiencing this as well.

[cyberman54]

I can confirm this behaviour, saw it several times.