NvmMangement in the LoraWan Stack

[Adamzat]

Hi all,

I have a question about the NVM context management.

Actually, we want to optimize the access to the EEPROM of our devices. Indeed, we would like to know:

• If we must store all the data managed by the LoraWan Stack (described in LoRaMacNvmData_t)?
  For example, it seems that the data used for the Join are necessary (like the DevNonce). But I am not sure for the others?

• What is the frequency that the data is updated by the LoraWanStack. Is it every uplink or reset? or it is random?

Thank you.
Best regards.

[bwesen]

In my recent experience it seems like it tries to write hundreds of EEPROM bytes for every packet received (which takes seconds on the STM32L0). I had to disable context management completely... there are not many comments anywhere in the stack so I couldn't dig deeper.

[kjendal]

Frame counter is not required if you will join after reboot

[kjendal]

To improve the security posture, in LW 1.0.4 DevNonce is required to be monotonic (always increasing). This allows the JS to systematically guarantee there has been no replay attack. JoinNonce is required to be monotonic in LW 1.1+ for the same reason towards the end-device. The support this requirement, the end-device must store these values.

[bwesen]

Yeah I think I understand the reasoning, but I fail to see how it can work in practice. No device can keep this stored correctly forever and no Lora GW can reliably store it forever either. If either of them loses it, should I ask my customers to throw away their products? :)

I wonder if there is a way to tell the Multitech Conduit GW to treat all devices as 1.0.3 and simply ignore this mess.. and vice versa for the device stack..

[kjendal]

I dont understand your point. The end-device and the Join Server need to store a single value such that they do not use a previous nonce (as they are a counter). That is not hard to do, in fact it is easier than what they were trying to do previously, which is to keep a list of previously used values. The gateway has nothing to do with it.

[bwesen]

Well the device can be factory reset or reflashed, the EEPROM CRC can break, miswrites or misreads happen. The gateway can get reflashed (the "Join Server" is just the gateway in the Multitech case). If this really was enforced, nobody would sell a product that can get bricked and not reset..

I'm sure there must be a way to just disable this enforcement in both the GW and the device.