Erasing LoRa stack after upgrade
- This topic has 1 reply, 2 voices, and was last updated 8 years ago by
.
Viewing 2 posts - 1 through 2 (of 2 total)
Viewing 2 posts - 1 through 2 (of 2 total)
- You must be logged in to reply to this topic.
Home › Forums › Conduit: AEP Model › Erasing LoRa stack after upgrade
Jason Reiss.
Manon ScatassiHi everyone,
With the upgrades of the last too months on both AP and Conduit gateways, I’ve witnessed twice the same behaviour : upgrading the gateway seems to “erase” the LoRa stack as I have to reboot my LoRa sensors for them to keep communicating with my gateways.
Seems quite logical to me as the session keys exchanged during the OTAA are certainly stocked in RAM, but is they’re any way for us to keep these informations even during an upgrade ? It is note pratical for us to reboot all of our devices one by one and we’d like to avoid this.
Thanks
Jason ReissThe upgrade from 1.4.3 to 1.4.14 had an issue with persistent db location.
This caused the db to be held only in RAM and not backed up to flash.
If after the upgrade to 14.14 the nodes were reset and rejoined this would only remain until reboot.
Upgrading from 1.4.14 to 1.4.16 fixes the persistent location but the sessions made to 1.4.14 were lost with RAM and could not be recovered after a firmware upgrade.
Upgrading from 1.4.3 to 1.4.16 should maintain the session information
from the previous version. End-device with unique appkeys registered through ‘lora-query -a’ command will be saved to /home/root/whitelist.jsonlines. They will not be able to join the network until the list is imported into the API.
See Upgrade Guide