i got some error
device-session does not exist or invalid fcnt or mic
any help!!! thanks!!!
i have 30+ device, god!
Sessions are stored in Redis. If you flushed it, they will no longer exist and the devices will need to re-join.
Your devices should probably have rejoin-after-X-confirmed-failures logic, if they don’t already.
device awlays re-join,but just got some error
device-session does not exist or invalid fcnt or mic
i don’t know what can i do for it
As @bconway already mentioned, when you run a redis flushall, all your device activations are gone and the error your are getting is expected. Your device(s) need to re-activate after which the error should be gone, as a new activation has been created.
1 Like
Hello Brocaar,
I used your docker-compose.yml template and extended it to accomodate all the features I needed. I had a chirpstack instance running on docker, and activated some sensors (Dragino LSN50v2). Everything was fine.
Then I started up another chirpstack instance using docker-compose on another Kunbus (industrial RPi). I registered the sensors using the WebUI, by typing in the DEUI+APPKEY’s. I know they are correct because everything worked on the previous instance. The device never sjows Lora-Frames and I get the following error message in chirpstack-network.server:
*level=error msg="uplink: processing uplink frame error" ctx=.... error="get device-session error: object does not exist"*
From what I understand this means the device has not been activated in Chirpstack. The only method with which to activate (and re-activate) the device, that I know of, is to push the reset button. But this is not always feasible since some devices have been installed on a construction site in places that are no longer accessible.
Downlink messages cannot be sent unless it is activated, so that’s also not an option.
Is there a way of automatically reactivating the device, or at least doing it remotely?
Or is this a feature which the device should have?
Hi all. @brocaar I stumbled into a similar issue, having lost all device sessions after a hard restart of the VM that hosts our experimental deployment of ChirpStack as the local Redis instance (one shared by more than ChirpStack itself) was not configured to persist data to disk.
Obviously this is not a bug but a mistake of my own, although I do believe that the documentation can be made more explicit about this and prevent others from making the same mistake. Redis is often deployed as an in-memory cache that can be fully regenerated upon restart and, even having gone through the requirements at Requirements - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server , I hadn’t realized that session data only lives in Redis itself and cannot be recovered from the database.
Although your docker-compose.yml example does register volumes for the redis container as per https://github.com/brocaar/chirpstack-docker/blob/5dcf5b2d9d801798c3d92bb2c0f9f558ebd5f549/docker-compose.yml#L40-L41 , I think it’d be helpful to be more explicit in the NS configuration example about the fact that persistence must be enabled in order not to loose session data.
No big deal for us, luckily, as this is all new territory and we’re taking our due time to learn, make mistakes and improve. Thank you for ChirpStack - it’s truly a wonderful bit of software.
Hi,
did you find any way to restore those session keys situated on Redis? I mean, these must be stored somewhere on one of the SQL databases, or at least some info there that could be used to regenerate the original keys to allow for communication? Maybe salted with a timestamp? (backtracking the time when those devices joined the first time is possible - its in the logs).
It’s really stupid to have devices that are unable to notice a lack of communication with ChirpStack and not try to re-JOIN, but that’s what we have now.