Transfer of device keys while using built-in network server

LPWAN Industrial Gateways / Concentrators
1

We need to operate local Lorawan networks to receive data from nodes for a client. Commonly, one single gateway is sufficient to receive data from all nodes. Thus we decided to use the built-in network server for simplicity and then forward the data using MQTT.

This setup works well for us with the WisGate Edge Lite 2 (indoors) and the WisGate Edge Pro 2 (RAK7289CV2, outdoors), using WisGate OS 2.2.8 and 2.2.10. The nodes are joined using OTAA.

However, we noticed a problem if we have to reset or replace a gateway: Restoring the backup works without a problem and most of the configuration and the application can be recovered. But the devices associated with an application are no longer known. I.e. the “last seen” is never and there is no longer a “end device address” associated with the EUI. It looks like the information from the join process is not restored (i.e. address, NwkSKey, AppSKey are missing). Thus, it is no longer possible to communicate with the nodes.

Confronted with this problem, we explored the following options:

  1. Program the nodes to automatically rejoin the network if no uplink is confirmed after a certain time.
  2. Manually trigger a rejoin for each node.

Unfortunately, some devices cannot be programmed and others cannot be accessed after installation. So these do not generally solve our problem.

  1. Digging further, I noticed that the information from the join process are stored in a sqlite file called mote_db (and mote_db.0). It is at either /etc/lorasrv/mote_db or /mnt/mmcblk0p1/lorasrv/mote_db and links DevEUI (pkey) to DevAddr, NwksKey, AppsKey. In principle, this is the information we are missing after a restore.
    So, I tried to back it up manually and then copy it to the gateway after restoring. But it seems like that information is not read by the gateway.

So my question is:
How can we make sure the gateway can still communicate with all end nodes after a restore of the gateway?
If anyone knows how approach 3 could be made to work, I’d appreciate it. But I am also open to any other approach that solves the problem outlined above.

I am aware that the problem is due to the fact that we are using the built-in network server, If the network server were independent of the gateway, this would not be an issue. For our simple setup, we would like to not have to manage an independent network server and would thus like to use the built-in functionality. The fact that WisGate devices are able to do this was one of the main reasons we bought them.

2

Hello @ywg Thank you for your detailed explanation.
This is an expected behavior due to the Security of the LoRaWAN network.
The issue you’re encountering is indeed related to how session data (DevAddr , NwkSKey , and AppSKey ) is handled by the built-in network server. These keys are generated and stored locally on the gateway during the Over-The-Air Activation (OTAA) process. For security reasons, LoRaWAN specifications ensure these keys are encrypted and hardware-tied, making them non-transferable in a readable format.
You can use the ABP to not have authentication during the join process.