Max value for device_session_ttl

Hi everyone.

I would like to confirm if there is a maximum value for the device_session_ttl configuration, as seen in this documentation.

I couldn’t find this info in the documentation.

Best regards

the value is not regulated.

Thank you very much, @eugenev

So, to test the configuration, I changed the device_session_ttl for a shorter value (such as 10s and also 1h0m0s), restarted the docker container and watched via the ChirpStack interface for the session to be expired after the configured time - losing the session keys. For some reason the session/keys were not lost after that time, what makes me think that the configuration was not applied.

I’m using the chirpstack/chirpstack-network-server:3 docker image. Was there any other steps to take in order to apply the configuration?

Thanks in advance for any further help.

I have not walked through the code, but it’s possible that the setting applies at session/key creation time and does not apply to existing keys. Have you tried rejoining your device(s)?

Thanks for the reply @bconway.

Yes, I even registered another device after the configuration change and the session stills active after the configured period (e.g. 10s).

I believe those tie back to redis ttls - can you confirm if those keys are showing up in redis with that ttl? And what key eviction policy you have set?

You can increase the device-session TTL in your chirpstack-network-server.toml configuration

Hi @John_Roesler, Redis is storing keys with 744 hrs TTL - the chirpstack-network-server default. It seems that the configuration was not properly applied indeed. Eviction policy is noeviction.

@sagarpatel, thanks for your answer, I’m indeed dealing with this exact config.


After reading @John_Roesler answer, it becomes clear to me that it was a problem with the config file itself - and it was indeed. The device_session_ttl key was placed under the wrong config section - a newbie’s mistake. After fixing it the keys began to be stored with the proper TTL and the session behavior is now as expected. Thanks @John_Roesler!

Thanks everyone for the help, it was most valuable!

Yes @bconway, after fixing the issue with the config file I can confirm that the existing keys are not updated - being so I had to reactivate my devices to apply the correct TTL. Thanks for pointing it out!