How can we ensure that a LoRa Device will rejoin after LoRa chirpstack network/gateway is restarted
we are using Dragino device (OTAA method)
You would need to ask the author of your device firmware. That’s where rejoin logic would reside.
Session data is saved in postgres.
Why should the device need to rejoin after a server restart?
Activation data can be lost if Redis is not configured with persistence (the default).
Thank you for response!
But if we keep the activation session keys in postgres/redis in a persistent matter, don’t we have a kind of lowering security requirements.
Latest firmware for Dragino does have the capability to rejoin.
The default is 2 days.
You can change the default value.
Btw, rebooting gateway should not affect the sessions.
@Oren_Zakaria
Where are the end-device root security keys stored?
I assume these are persistently stored in postgres?
Is redis persistence less secure than postgres?
Sooner or later sessions will be lost, and the modem does not know this happened, and will keep sending data, but CS can’t use it anymore, sees it as noise basically.
What I do is monitor for downlinks as a sign of a good connection (including time-syncs). A couple of days without downlinks and then I restart.
I agree it is good design for the end-device to be able to recover from a catastrophic failure on the network side and session context is lost due to corrupted data or other unforeseen issue.
I see it as bad general design to throw out session context to restart the network service for deployments.
The default is non-persistent session context in redis.
The service provider can choose to enable redis persistence. My choice would be to enable redis persistence.
Actually, I think that depends on the distribution. For Debian / Ubuntu, persistence is enabled by default in which case the data is periodically written to /var/lib/redis/dump.rdb.
1 Like