Lora Server misrepresenting frame counter most significant 16 bits
- This topic has 2 replies, 2 voices, and was last updated 5 years, 4 months ago by
.
-
We’ve recently upgraded one of our Conduits to firmware 1.6.4 and been having a hell of a time getting our ABP node stable. After much investigation, I’ve discovered the following:
- After a few successful transmissions, the Lora Server’s “LAST-FCNT” increments to say, 00000004.
- When our Node (RN2903 based) power cycles it resets the frame counter and does a new ABP join before transmitting.
- The node sends FCnt = 0000 (or other low value), but the Lora Server interprets it as FCNT: 00010000 and it discards it due to exceeding the MAX_FCNT_GAP. This is confirmed by reading lora-network-server.log and eavesdropping on UDP port 1784.
- The node keeps incrementing until FCnt=0004. At that point the Lora Server drops the 17th bit and reports FCNT: 00000004, discarding the packet as a duplicate.
- The next packet is FCnt=0005, correctly interpreted as FCNT: 00000005, and all is well again.
- At this point the server often seems to send a downlink which causes the radio in the Node to hang, but at the moment I believe this to be a separate issue.
This is very reliable behaviour, persisting through session resets, fcnt changes, abp joins, otaa joins, device resets/adds, etc. We have never seen these frame counter errors before. I’m not sure how Lora Server keeps track of the upper 16-bits of the frame counter, but it certainly seems to be a mistake in this instance.
Can anyone confirm or deny the existence of a (new) bug in the incrementing of the upper 16 bits of the 32 bit FCNT? Or possibly it’s always been this way and it is a MAX_FCNT_GAP issue?
FWIW, it’s not possible for use to make changes like saving the current frame counter on the Node. We need to be able to fix this from the Conduit end.
Thank you, the linked reference answers my questions perfectly (except whether this is new behaviour, but that’s no big deal).
From the references:
Why the CHECK-PKT|FCNT is +10000 after the reset?
The server is checking if the 16-bit counter has rolled-over since the last packet.Which when combined with this:
The FCNT is expected to be only increasing per LoRaWAN. An FCNT should only be used once per set of session keys. The FCNT is only reset when OTA join is received.
Explains the primary issue. Then this explains how to disable the check (with obligatory security warning):
http://www.multitech.net/developer/forums/topic/disable-enablestrictcountervalidation/
- You must be logged in to reply to this topic.