Warning text for "reset frame counters" is incorrect

[avbentem]

This is a bug report for the console.

What do you want to do?

When I reset the frame counters I want to understand that really bad things can happen.

What steps did you take?

Click "Reset frame counters" in TTN Console.

What went wrong or what is missing?

As per (my own) #626 the warning/help says, emphasis mine:

Are you sure you want to reset the frame counters?

⚠️After resetting the frame counters, any uplink counter the device sends will work. However, the first downlink sent to the device will have a zero frame counter. This implies that the downlink counter in the device needs to be reset as well.

However, "any uplink counter the device sends will work" is false:

• For 32 bits counters, if the current uplink counter exceeds two times 65,536, then TTN will not be able to validate the MIC, and will (silently) discard the message even though the new uplink counter is larger than the last-known value of zero.

  This is due to the LoRaWAN 1.0.x message only including the 16 least-significant bits (LSB) of the counters, while after resetting the frame counters TTN will only consider 0x0000 and 0x0001 for the MSB; https://github.com/TheThingsNetwork/ttn/blob/master/utils/fcnt/fcnt.go#L16 Hence, for large values of FCnt, TTN will not find a matching MIC.

• Maybe, but unverified, it's even worse as LoRaWAN defines MAX_FCNT_GAP, being 16,384, which might imply it even rejects messages for which it can actually find a matching MIC.

So, for large values of a 32 bits FCnt, resetting the frame counters might also require resetting the uplink counter of the device. I suggest to make the warning message far more scary. Maybe:

You should only reset the frame counters if you are sure that the device's counters have been reset as well. When the device is not reset, the device's messages will be rejected if its current uplink counter is much larger than zero. Also, the first downlink sent to the device will have a zero frame counter. This implies that the downlink counter in the device needs to be reset as well.

Asides:

• One might be tempted to make the message more specific given the current value of the frame counters, but as messages might be received while the warning is shown, or might be lost after the reset, that's probably just introducing new edge cases.

• Alternatively, TTN could keep the previous values too, but then: what if the user resets the counters multiple times. And it's not the responsibility of TTN to resolve human errors.

• One might think TTN could try all 65,536 possible values for the MSB, when TTN knows the counters have been reset. However, a DevAddr is not unique. So, to uniquely identify a device, TTN needs to calculate the MIC for all devices with the same DevAddr. Assuming that the other devices using the same DevAddr are sending messages as well, this implies that TTN might repeatedly need to try all 65,536 MSB values for a device that had its counters reset, until that device indeed sends a proper new message, if ever. That will not scale. Also, this does not solve any problem for out-of-sync downlink counters.

• An actual use case in the forum: Payload is shown on gateway traffic but not in application, maybe caused by adding Collos integration.

Do you have Screenshots?

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

N/A.

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

N/A.

What do your configuration files look like?

N/A.

What do your log files look like?

N/A.

Can you fix this yourself and submit a pull request?

No.

[johanstokking]

CC @kschiffer @bafonins

[htdvisser]

I don't think the v3 console should just copy the "reset frame counters" functionality in its current form. Instead it should have functionality to inform the network server about what's actually going on: an ABP device device completely lost its state. This state is more than just frame counters, as the device also lost its MAC state and radio parameters.

879 [...] The frame counters (both uplink & downlink) SHALL NEVER be reset in ABP
880 devices.

Considering that frame counter resets are forbidden in LoRaWAN 1.1 (and were already highly discouraged in LoRaWAN pre-1.1), I propose that we call this functionality simply a "device reset". This will completely reset the device to its initial state. For ABP devices this means destroying all session information, for OTAA devices this should destroy join nonces as well.

The UI should indicate that doing this is (A) not spec-compliant (B) not secure and (C) requires the device to be reset to factory state (if it didn't already do that by itself).

cc: @rvolosatovs

[rvolosatovs]

Indeed, "device reset"/"factory reset" functionality would make more sense here IMO, however I believe that would just be a shortcut to simply deleting the device and re-creating it.

[hiyasbie]

Hello, I have the same problem as this. I clicked reset frame counters and now I can't see data from my node/device in my TTN console. How to solve this? thank you. by device/factory reset, meaning click the reset button(next to LED) from lopy4?.. thanks. (newbie here)

[johanstokking]

@hiyasbie this is too specific to the device and the software to answer this here. Please consult the forums; https://www.thethingsnetwork.org/forum

[htdvisser]

This is not going to get fixed in V2 anymore.