Source of Problem: Missing Data caused by interrupted Internet connection, while gateway decides to go to full reboot. After reboot a device happens to send new data packet, which is processed correctly. How to reenter the missing data, which I have in logfiles of simple packet forwarder?
When replaying the missing data, the frame counter validation fails intentionally for security reasons. But setting the checkbox for ‘disable frame counter validation’ for a while, I realized that this option is not effective. Replaying is still not possible.
I checked the configuration:
checkbox is selected, then “update” button executed. Logout, Login, got to device and I see checkbox is selected.
But still resending one packet with fCnt 47 via bridge to server fails with
“error:“frame-counter reset or rollover occured”
The current uplink fCnt is 62.
Just to mention, when I relay new data with fCnt=63 or above with my same method, the data is correctly processed in chirpstack. My problem is with frame counter validation, although it is set off.
ChirpStack networkserver: 3.10, Gateway bridge 3.90 on kerlink iFemto gateway
From my experience, the way the protocol is designed as you note is to prevent replays. So, in the event the gateway goes down without sending packets in the queue, I do not believe there is a solution today.
This sounds like a case where you may want confirmed messages (if that is allowed in your region). That way if the gateway is down and the uplink or downlink never reach their destination, your device would know to retry. The issue with a downlink ack of a confirmed message being lost is that the Network Server won’t know it never made it to the device. So the device’s retry will be rejected. We’ve seen this happen occasionally and our device retries several times and then rejoins and sends the packet again successfully.
Hi John, thanks for being welcomed in the community.
I’m following the capabilities and feature of Lora just from the start of first published LoraWAN Protocol a few years ago. So, yes i agree it is a security problem, when i switch off frame counter validation permanently.
The logic behind confirmed messages has to be activated by the vendor of a device. Many of them allow to configure Lora parameters and also many do not allow. I have devices from both types of vendors. The particular device of interest in this topic doesn’t allow to change lora parameters, so it is bound to be in unconfirmed data uplink schema.
Also i looked into related topics posted regarding missing data. Conclusion so far is, it would be great if gateway bridge persists mqtt queue to local db or file until message is ack by network server (mqtt.qos =1 on both sides). This way sensor data is kept safe while internet is off. Forwarding them as soon internet is back online.
In my case the gateway has conman and network manager scripts from vendor kerlink, which eventually reboots if internet is failing a longer period (i guess one or more hours). The current gateway bridge (v3.90) has its db only in RAM and not on file-storage. Loosing all sensor data, if rebooting.
For my work around it would be great if disable frame counter validation by using that checkbox in network server ui is working. Its not working! Seems to me that UI promises too much.