We have encountered an issue where Chirpstack V4 intermittently loses network keys for ABP devices. This issue arises without any user-initiated restarts or overwrites, leading to unexpected disconnections from our server. Is this a known problem, and what are the recommended steps to identify the root cause?
Upon further investigation, we’ve discovered that the Redis database has a persistence duration around 30 days (is this correct?). Given that ABP network keys are not automatically updated, could this be a contributing factor to our issue? Does Chirpstack address this situation in any way, or is it required to manually update the ABP device values every month to maintain connectivity?
Please note that every frame-counter update causes a new write to the Redis key which re-sets the TTL value to 30 days (default value for session TTL).
The issue persists with devices that will connect once per month or even less frequently. What should be done with such devices? Is it acceptable to extend the persistence duration up to 6 or even 12 months, or should do some custom script to keep these devices prepared for connection if they haven’t connected in one month? This also is a problem where keys are loaded ie. when device is sold, but only started some months later.
Yes, you can increase that to a longer period. Note that the TTL takes effect after the next write to Redis. In other words, if you change it now, it will not automatically extend the TTL of keys already written. However, you could create a simple script (Go, Python, Rust, …) which iterates over the Redis device-session keys and extends the TTL.
