Hi, all, this will probably be a feature request, but I do not have the latest version of the software… Can anyone check if this problem still exists on the later versions of GatewayOS? ( my build is sort of special from december) Does the ABP keys get expired when you have no internet? or set the clock wrong on the raspberry?
— long chatty version —
Server run networks - We had some ABP configured nodes in storage for a month and then I discovered that they did not work and I had to re-configure the keys on our chirpstack server ( a very old version, running on real server hardware ). Looking into this I found that chirpstack sets a TTL value on both OTAA and ABP devices to 1 month on the Redis database entires. Thus any ABP devices that does not transmit data o the server for a month gets it’s keys expired, even though it still exists as a device.
There are a lot of issues regarding this Time To Live/Expire thing over the years, and it seems the generic advice by Broocar is to set it to such a high value it will not expire.
Example of bug-report/issue - https://github.com/brocaar/chirpstack-network-server/issues/300
Embedded networks - We use the GatewayOS on raspberries that are powered on and part of a control-system for a few months a year, with hardcoded ABP temperature devices ( feeding data into a fan-controller ). Thus with only power a few months a year, we must be able to change this settng.
- I can’t find out how to set the TimeToLive value on the GatewayOS at build-time? How can this be done?
- Clock. Redis requires a stable clock that does work.
“Even running instances will always check the computer clock, so for instance if you set a key with a time to live of 1000 seconds, and then set your computer time 2000 seconds in the future, the key will be expired immediately, instead of lasting for 1000 seconds.” - https://redis.io/commands/expire#expires-and-persistence
The raspberry does not have a real-time clock that is battery backup-ed. Thus it can basicly be at any kind of time when a device is configured, and if it does find a time-server or sync it’s clocks it could really expire all encryption keys. I really wonder what happens if it has the real time, and then get a clock that is from 1970… ? (I’m not sure about the time set at startup, but I assume if a sensors sends in a value with a clock that is from 1970 and then after a while it gets a message to decode from 2020 it will just expire the keys)