Device-activation table in Application Server

ChirpStack Application Server
1

Greetings!

Recently we discoverd that it appears the device_activation table in the Application Server is not populated with device activation data (dev_addr and app_s_key specifically). We are wondering if this is a recent change that is part of an update and if so, when did the change take place?

We have a private LoRaWAN infrastructure and use a central ChirpStack server to make configuration changes to multiple replica ChirpStack servers in remote rural areas with inconsistent WAN connections back to our campus for data gathering via Postgresql Logical Replication. Previously we were able to update device configuration information on our master configuration server such as Variables and Tags without and the changes would replicate to all our remote servers without issue. Recently we noticed when we make a change to a device on our master server, the Device Address and App Session keys are now overwritten. When setting up the replication we specified tables to replicate rather than the entire database, leaving out certain tables in the NS and APP server dabases (device_activation being one of them) that contain more dynamic configuration generated at each remote site. This allows our researchers to move device between sites and only have to re-join the device to continue their work. The concept is similar to Domain Controllers in Active Directory.

Re-joining the device regenerates the necessary keys to allow the data objects to be decoded and processed as normal, but now any change overwrites those keys. Previously we believe the keys to be stored in the device_activation table on the app server and referenced by the device table. Leaving the device_activation table from replication left the keys intact but they are now ovewritten when replicating changes to the device table resulting in no data decoded or recorded.

For the time being we believe we will need to revert back to the Chirpstack version before the table changes and are trying to identify this version.

Information and ideas are greatly appreciated!

Thanks,
fwolf

2

In the latest version(s) I have been working on some performance optimizations. One of the optimizations was to store the session-keys within the device record as this avoids an additional query on every uplink / downlink :slight_smile:

The reason the device_activation table is still in the database (but not used) is to be able to provide a rollback in case of any issues (e.g. when I made a mistake in the database migration). This table will be removed in one of the next versions however.

Note that from the outside (when using the API methods), this does not change anything. However, when you are querying the database directly, then you might need to make changes in your code.

3

Thank you brocaar!

I think we are looking at reverting the db and server versions until we find a way to develop a solution (active-active postgresql clustering?) or redesign our management solutions (external API console?).

I believe our situation is somewhat unique compared to most ChirpStack users with a central management console but allowing autonomous local operation and data gathering. Kind of the bane of rural sites with little to no cell service and unreliable internet access. Other than this change ChirpStack has met all of our needs.

If anyone else has a similar setup/situation, advice is very welcome.

Thanks again,

F

4

Where does the activation configuration store? because I have Chirpstack in kubernetes with a Configmap to enter the * .tom configuration file, everything works fine, but every now and then the device activation configuration is lost, which makes me think that it is stored somewhere inside the container and I need to assign a persistent volume.

5

Device activation data is in Redis. You definitely want it to be persistent, and probably have a backup strategy, depending on your application.

2 Likes