Hello,
I’m using loraserver with 6 LoPy deployed about 2 or 3 years and working flawlessly, but one month ago something happened and loraserver services went down a number of days still to discover, and now I think the devices have lost it’s session.
Under loraserver logs I can see the following: error=“get device-session error: device-session does not exist…nvalid fcnt or mic” and under Lora-App-Server I can see live lorawan frames correctly, but no reflects under the application.
It’s possible to make a remote reactivation? The nodes still think they are joined to the network and send the packets correctly.
Or maybe it’s possible to do some kind of change under lora-app-server in order to make the nodes reactivate or rejoin again? (I have disabled frame validation)
The nodes are deployed far away and it’s difficult to access them, so just asking if it’s possible to avoid traveling and locating the nodes.
Best regards
Are these OTAA (over the air activation?) nodes? If so, unfortunately no there is no way to force them to re-join, and if the server has “lost” the session secrets there’s really nothing to do at all.
For that reason nodes should have their own timeout where after receiving no responses they will start trying to re-register themselves.
What sort of raw traffic are you seeing? Ie, are you getting join requests, or are you still getting something with the length and pacing typical of application traffic, but encoded with secrets you no longer have?
2 Likes
Hello, unfortunately the nodes are OTAA activated, and under raw gateway traffic I’m seeing the packets with the normal application pace but as you said, encoded with bad format (as now I don’t have the new secret).
Maybe loraserver database has a backup of the last keys used? just praying…
Probably time to arrange a travel to the location then…
Those are stored in Redis. Are you running Redis with persistence enabled and/or backups?
I don’t know if persistence was enabled (never used redis before) will check tonight. Loraserver was installed manually following the web instructions, and I have no backups from the system at time of activation.
Not a direct solution to your problem, but these kind of things should also be taken in mind when engineering a device firmware. E.g. validate the connectivity with the network and in case the packet-loss exceeds a certain threshold, re-join.
2 Likes
Thanks brocaar, finally went to the installation to reset manually the nodes and all working fine. I need to implement some packet control in the near future.
Maybe, the possibility/idea is to have a nvs variable to keep the number of communications and then request from node to gateway application some kind of ping command, then if no response do a rejoin.