LoRaWAN 1.1 devNonce must be stored in a non-volatile memory on end device

TTN V2 to V3 Upgrade
4

I’ve not found any requirement to store the DevNonce in NVM - it just requires that the DevNonce increment and makes the suggestion that IF the power were to be restarted, that it may be useful to store it in NVM for retrieval at startup.

For deployment of a device, it joins, it runs, it’s batteries die, it gets left to form part of the sedimentary level causing a strange shape in the rock when the aliens arrive to find out what happened to us after the seas rise and we go though another ice age. IF the device happens to be restarted due to a battery change or other reason, its first, possibly second join will fail but as the NS won’t exactly be holding a value in the low teens, after a few futile tries it will join. Personally I’m likely to have something I can save settings in on the board, so having a stub for the developer to add saving settings, if the use case deems appropriate, is OK.

We already have had this issue come up with SAMR34 devices here where developers were testing using OTAA, hadn’t read the MLS release notes and get road blocked. Clearing the DevNonce at the command line is easy enough and switching to ABP for radio testing (and not using the radio when not testing the blindly obvious bit about sending) should solve most issues.

@mluis1, can you point me at your work in progress and I can see if it’s feasible for me to pick it up.

5

For DevNonce persistence requirement please refer to the LoRaWAN 1.0.4 Specification Package document chapter “6.2.5 Join-Request frame”.

image

The DevNonce storage in a NVM is used to avoid compromising the security of the node.

The LoRa-Alliance also provides a technical recommendation document on how to develop a LoRaWAN end-device.
Developing LoRaWAN® Devices v1.0.0.

I will provide here as soon as possible the link for the SAMR34 update progress.

6

@mluis1 and @descartes, thanks for the confirmation. I needed to make sure that i interpreted the specification correctly

7

Thank you, but I’ve read it before, several times, hence my original commentary - and for readability I’ve adjusted the image - please do not post images when you can copy & paste text.

The security of the node is up to the creator, it would only need to save the DevNonce if it was going to be certified, but then some storage may well be on board the device.

Not supporting SAMR34 because it doesn’t have internal NVM is taking a suggestion in the spec about how something should be done and extending outside of the reality zone of real life.

8

@descartes I have just pushed my work in progress to update LoRaMac-node SAMR34 support.

The link to the issue is: Update SAMR34 platform · Issue #1111 · Lora-net/LoRaMac-node · GitHub
The link to the pull-request is: Update SAMR34 platform by mluis1 · Pull Request #1112 · Lora-net/LoRaMac-node · GitHub

If I remember well I was working on updating the uart-board.c file.

Please note that the project compiles successfully however it may not work as expected.

1 Like
9

Thank you for adapting the image size. I used an image because it was easier to highlight the text.

The specification mandates the use of some sort of persistent memory.
“If the end-device can be power-cycled, then DevNonce SHALL be persistent (e.g., stored in a non-volatile memory)”
The important word here is SHALL.

The aim of the LoRaMac-node project is to provide examples that work out of the box using the supported platforms.
In SAMR34 example we try to use the internal MCU FLASH memory because the SAMR34 development kit does not provide any other possibility to persist data out of the box.
Nothing prevents the user to connect an external I2C/SPI NVM and adapt src/board/eeprom.c to use an external memory instead of the MCU FLASH memory.
All the provided examples require to have an NVM because all of them should pass the LoRa-Alliance pre-certification tests as well as to provide recommended good practices examples.

As a side note I think that security must be taken into account since the beginning of the end-device development. If we say we will do it later it will almost certainly not happen (will forget to do it at the end of the project development, time constraints to deliver the final product, etc…).

10

It would still be useful though if LoRaMac-node and the examples can use a modular mechanism for storing state, one which is not NVM type (or MCU family) bound.

E.g. by registering a callback(s) that does the actual reading and writing of the state data to and from NVM (whether builtin to the MCU or some type of external I2C or SPI NV storage).

This will make it easier to port to other architectures and other hardware.

1 Like
11

@bluejedi At some point we still need to have access to the hardware that is able to store the data.

The purpose of src/board/<platform>/eeprom-board.c is to provide such interface implementation.
In case a user wants to use a different way to store his data it just needs to adapt the contents of eeprom-board.c to the used hardware.

Long time ago the LoRaMac-node project supported a platform which had an external I2C EEPROM on it.
You can find that implementation at following link LoRaMac-node/eeprom-board.c at v4.4.0 · Lora-net/LoRaMac-node · GitHub

When porting the LoRaMac-node project to another platform one is just required to implement the drivers under board directory. The minimum set of required files are listed in following document LoRaMAC: Porting Guide

12

I haven’t checked that code and the interface but that does not sound like modular design (to start with just the filename… eeprom). E.g. my FRAM would feel very disrespected with such a name.

I expect better from an essential library as LoRaMac-node. :sunglasses:

13

I’ve fully acknowledged the specifications requirements, I’m referring to the non-mandatory eg that has ended up with a “No NVM on SAMR34 therefore no further support” in the release notes. Nothing in the specification means you can only service MCU’s with internal flash/fram/dot-matrix-printer-with-OCR.

Providing sane & sensible links to allow the device designer to link any storage mechanism they like is much more flexible, as @bluejedi says, than just dropping the core line from one of the major silicon providers.

So why not create an example for the SAMR34 that has a secure element in the mix. Although it is quite bizarre that Microchip didn’t put one on their SAMR34 or WLR089U boards.

Good to know. I’m in full agreement, it’s something I’ve been doing for a while now.

If you re-read what I typed, you see I never said anything about retro-fitting. But what I did imply is that shipping a device without a way of storing the DevNonce is up to the designer & the end user. Particularly if the unit is sealed with it’s batteries (I’ve made a few, I’ve got a third-party moisture probe like that), then it can’t have it’s power cycled so the SHALL becomes irrelevant.

And from where I sit, people pulling the little bit of plastic out the battery hole and sticking the device somewhere to never be looked at ever again is definitely a thing. So the power can’t be cycled, so no NVM required …

A very wise man, @kersing, once said, as long as it is not detrimental to the network, then some flexibility should be expected. A device having an upset and taking two or three goes to advance through the DevNonces isn’t going to be the end of the world.

But, and here’s the kicker, you can tell why a device has restarted from it’s power manager - as seen in the Microchip offerings so we have the option of incrementing the DevNonce by a chunk & a bit, say from 1 to 11 (I like prime numbers). So it can have two goes at joining without disrupting the specification’s karma.

14

There are plenty of things that could be improved.
Also I have plenty of ideas for improvements. The problem is the lack of resources and time to do such improvements.

As the name eeprom-board.c does not look to fit your requirement you could just rename it as well as the APIs in order to fit your requirement.

As we are diverging from the original question I will stop here. We may maybe continue this interesting discussion at the following link Discussions · Lora-net/LoRaMac-node · GitHub

3 Likes
15

@descartes
Now I understand the confusion.
I guess that I did not choose the right words for the changelog file.

Known limitations

    SAMR34 platform does not support NVM storage. This is a requirement for LoRaWAN versions greater or equal to 1.0.4. No work on this subject is forseen by the maintainers. Implementation proposals are welcome.

What I meant is that: “Currently the SAMR34 platform does not support NVM storage by lack of drivers implementation.”
The sentence This is a requirement for LoRaWAN versions greater or equal to 1.0.4 was to inform that currently we cannot run the pre-certification tests due to the missing NVM storage support.
The sentence No work on this subject is forseen by the maintainers goal was to indicate that adding this support is not supposed to happen in the near future.
In the mentioned text we also ask for help on implementing this support in order to speed up the process.

In addition I have already started to implement such support (few posts above). The problem is the lack of time to finalize it.

I will update the changelog in order to be more clear.

2 Likes
16

For the sake of completeness:
According to the LoRaWAN 1.1 specification

the devNonce and the JoinNonce should be stored at the device.

The device keeps track of the JoinNonce value used in the last successfully processed Join-accept (corresponding to the last successful key derivation). The device SHALL accept the Join-accept only if the MIC field is correct and the JoinNonce is strictly greater than the recorded one. In that case the new JoinNonce value replaces the previously stored one. If the device is susceptible of being power cycled the JoinNonce SHALL be persistent (stored in a non-volatile memory).

17

But if it can’t be power cycled, it SHALL form the basis of a battle of wills between corporate business and a small entrepreneurial electronics business based in the North of England …

18

It is interesting wording to have SHALL but to undermine it so completely with “susceptible”. I think @descartes is completely correct with his implementation; his devices are not susceptible and so the SHALL doesn’t apply. Even a unit with replaceable batteries in O(years) wouldn’t be considered susceptible, my threshold would be “mains powered” but ymmv.

The title of this topic is therefore incorrect too; they should be stored and compared, but lack of persistence is not a violation of the spec. Is that the position you arrived at too @robertlie ?

These are useful discussions to get us to v1.1+

2 Likes
19

That also includes v1.0.4.

In theory (and practice) every device, appliance is susceptible to being power cycled (if not intentional then accidental).

To keep things simple, i.m.o. for new LoRaWAN developments it will be best to allways include and use some form of NV storage. (Yes, to make things ‘simple’, reliable and keep them working usually requires more work.)

1 Like
20

@bwooce my interpretation is: both DevNonce and JoinNonce shall be stored in a Non-Volatile Memory (NMV). End-devices maybe solar powered, maybe maintained (eg plastic box damaged, send to repair), maybe moved from one location to another (eg beehives) but for the last 2 cases it maybe useful to power down the device for accurate data recording. If the DevNonce and JoinNonce are not persistent stored it will be difficult to make these devices work correctly again.

1 Like
21

Or just take a few join tries before they succeed.

But if a device is solar powered or could be sent for repair or is attached to a beehive, then this isn’t the use case I’m looking at so I’d put some NVM on the board.

And I’d put NVM on most boards anyway.

But I won’t be putting NVM on a low-cost device that is sealed because it’s not a requirement.

1 Like
22

@descartes, according the LoRaWAN 1.1 specification, the Network Server checks the DevNonce and the end device checks the JoinNonce.

In the specification this is what it says about the DevNonce (in verbatim):

DevNonce is a counter starting at 0 when the device is initially powered up and incremented
with every Join-request. A DevNonce value SHALL NEVER be reused for a given JoinEUI
value. If the end-device can be power-cycled then DevNonce SHALL be persistent (stored
in a non-volatile memory). Resetting DevNonce without changing JoinEUI will cause the
Network Server to discard the Join-requests of the device. For each end-device, the
Network Server keeps track of the last DevNonce value used by the end-device, and
ignores Join-requests if DevNonce is not incremented.

So, if a Network Server developer implements it according to text above than your low-cost device, with no NVM, will not work.
Multiple join tries will also not work.

Unless I completely misunderstand the text about the DevNonce.

Please note I don’t have a specific position on this matter.
I only want to check if I understand the LoRaWAN 1.1 specification correctly.

23

See previous post: