Hello,
something in advance: I have a small Lora Devices with which I can unfortunately only use ABP due to the low memory.
I migrated my application to the V3 variant some time ago and everything worked fine until yesterday. (Unfortunately I have not tested the reset case extensively). Current value: 7693
On my V2 gateway I see the sent data, but nothing arrives in the V3 application.
I guess that the packets are not accepted despite the setting “reset frame counters” enable inmy application.
(At a reset my counter starts counting again somewhere at 400).
Hello Joei,
Make sure you get access to the cli (command line interface) and the set the counter to the expected value by the command: ttn-lw-cli end-devices **set** <your application-id> <your device-id> --session.last-f-cnt-up <count>
for the upload messages. ttn-lw-cli end-devices **set** <your application-id> <your device-id> --session.last-a-f-cnt-down <count>
However it’s better to set you counter in the node to 0 when you reboot your device. The “reset frame counters” is working now in the things stack v3.12.
hello,
You’re welcome. I think it does not work in your situation because you do not reset your counter to 0 or 1 but to 400, as I understand from your question. When you reset to 0 or 1 it should work. I have not tested myself, I have confirmation from another guy who had reset counter problems on V3.11 and now working on V3.12.
Usually you start your node and it will run forever and the counters will turn over to 0 after 2^16 (-1). This is normal behaviour. When you send a non-successive counter, The Stack assumes this is not the right node. Remember that DevID’s are not unique. The Stack uses a combination of DevID and uplink counter as virtual ID’s. The uplink counter cannot make big leaps, especially jump to a lower value. When you enable the reset Frame Counter, the Stack accept a reset of the counter to 0 or 1, when you suddenly jump to 400 the node is no longer identified and the LoRaWan packet is dropped.
I hope this will answer your questions.
Leo.
The stack actually uses the DevAddr and NetSKey and uses it to calculate the MIC. If the MIC matches the right device has been found and the data will be delivered (decrypted using the AppSKey) to the application.
This works for any counter value that is between the last valid value and that value + 16384. Keep in mind a LoRaWAN packet has just 16 bit for the counter value while the node and the stack use 32 bit.
If the counter for a node increases beyond 65536 the value in the uplink packet will show just the lower 16 bit, seemingly a small value when in reality it is a large value. That larger (32 bit) value is used to calculate the MIC which will not match. The counter may seem to be within the 0 to 16384 window that’s valid after a counter reset while it isn’t and as a result the MIC values do not match.
To clarify, if I have a device that exceeds the 16 bit count, say it gets to 65540, so it transmits f_cnt as 4, and the NS has it down as 65540, how does it manage to match up?
I’ve got a couple of AA battery tests running on ABP that are +100,000
The backend keeps track of all 32 bits just like the node itself does. The lower 16 bits are taken from the uplink, the upper from the NS and the combination should be within the acceptable range. The exact logic is a bit more complicated but it boils down to this.
(My canary exceeded 1 million packets after running for years before I accidentally power cycled it while rearranging my office)
