We use ABP devices that have 32-bit FCnt, but in the LoraWAN 1.0.x specification, only the 16 LSB of the counter is transmitted. So, LoRa Server has to “guess” whats is the upper part (16 MSB) of FCnt to calculate MIC correctly.
So if device is never seen before (or the Skip FCnt validation is active), LoRa Server should not try all possible 65,536 values for MSB until a valid MIC is found? Since that if this device is already in network a long time, the 32 bits Fcnt is possible over 65535.
I had look on the LoraServer source code, and the validation process described in device_sessions.go and phypayload.go seems to me that validation only test the Fcnt + gap, not all possibilities.
In resume: since all devices in our tests are 32 bits FCnt thas is bigger the 65535, and the uplink package is always Unconfirmed, I don’t see how to sincronize the ABP devices and LorServer without reset the end device FCnt.
LoRa Server does not guess, internally it keeps track of the 32 bit frame-counter. Please see the unit-tests of this and “resolves” the full 32 frame-counter from the communicated 16 bit frame-counter, before it calculates / validates the MIC.
Yes, its keep tracking, but assume the following situation:
1 - Device, ABP, reset FCnt (=0x00000000), installed on a remote point, never receive by gateway
2. Few months later, the FCnt of the device is 0x00456789.
3 - The device now is in a range of a gateway, and the uplink finally arrive at Loraserver (1o packet that LoraServer received by gateway).
4. The uplink FCnt arrive at value 0x6789, 16 LSB, but the MIC is calculate from 32 bits value 0x00456789
5. How LoraServer knows the 16 bits MSB value of FCnt is 0x0045, in order to calculate the MIC ?
Hi Douglas
I was asking myself the same question and I’d add a comment : in the case you describe, the difference between the counter of the device and the counter of the server would be over MAX_FCNT_GAP, which is set to 16384 (2^14). The LoRa Spec 1.0.3 says at lines 516-520 that when the difference reaches this limit, the subsequent frames are discarded anyway.
For the frame you describe, sent with counter 0x00456789, the fcnt field would be 0x6789, which is above 2^14, so the frame should be discarded by the server without a try to calculate the MIC.
If the counter were 0x00010001, the fcnt field would be 0x0001, so the frame wont be discarded for being over MAX_FNCT_GAP, and the server will try MIC calculation with fcnt = 0x00000001, the MIC won’t match and the server will then report a wrong MIC for the frame (which is not the correct error report, but well anyway even with the good MIC, the frame would have been discarded)
So in the end, this means that the situation you describe breaks the max gap counter condition, so is not compatible with a LoRa network, but could lead to a bad interpretation by the server of a MIC mismatch.
It wouldn’t be discarded if the gap from the previous heard fCnt was allowably small.
An idea of what could have happened is that the server watched the node run up to an fCnt of say, 0x00456788
Then the node was reset, and the server started rejecting these “replay” packets.
Finally reset node climbed up to a value never before seen: 0x00456789 and the traffic started being accepted again.
The only problem with that theory is that at one transmission a minute, this would take about 8 years. So either that node is transmitting absurdly often, or the number reported are made up, or something else actually happened.
I don’t see how to sincronize the ABP devices and LorServer without reset the end device FCnt.
This is one of a number of ways that literal by-the-spec LoRaWAN, while “mostly right” seems to not quite fit well with real application needs. Many would suggest using OTAA, but that adds additional issues.