LoRaWAN device join process can succeed only follow counter dev nonce when device is reset. Can this be modified ?

[Candra SN.]

I have a LoRaWAN end node project with STM32CubeWL MCU Firmware Package v1.3.0.

I'm using LoRaMAC version 1.0.4. What confuses me is why my end node device can successfully join to the gateway based on the increment value of the dev nonce.

The detailed explanation is like this:

When the device is turned on for the first time, the device successfully joins the gateway on the first request and the dev nonce value is equal to 1. Then when my device is reset or turned off then turned on again, the device fails to join the gateway on the first request and the dev none value is equal to 1. But when in the second request and the dev nonce value is equal to 2, the device successfully joins to the gateway and so on like that.

Why did it happen? Is it based on the LoRaMAC version I'm using ?

What I need is that the device will attempt to successfully join to the gateway on the first request when i.e. it is reset many times, regardless of the value of the dev nonce or any other parameters. Is there a solution to my needs ?

Note: I'm using the default parameter settings from the example project LoRaWAN end node with AS923 region.

Any assistance would be greatly appreciated

[Arya1992]

I had a similar issue with the older version of STM32CUBEWL and fixed that then, I recently upgraded to STM32CUBEWL V1.0.3 and encountered the same issue. 

The reason why your end node is not joining after resetting with Dev-Nonce 1 is that the join-server already stored the Dev-Nonce 1, according to Lorawan Specification end node cannot use the same Dev-Nonce it has used previously, the join-server will simply reject that. When the end node sends a second join request with Dev-Nounce 2, that gets accepted because Dev-Nounce is new for the join-server.

This is taken from LoRaWAN® L2 1.0.4 Specification that talks about same thing.

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

Fix: Dev-Nounce must be stored in NVM (Non-Volatile Memory), before sending a join request, it must be read from the NVM and incremented. I don't understand why STM32CUBEWL V1.0.3 is not storing that in NVM.

Hope this helps.

[SLevi.1]

I have similar issue. At which point is the nonce supposed to be stored in NVM? Upon sending any [successful or unsuccessful] join request, or only when a join request is accepted?

I am using the latest software pack, with v1.0.3 Lora, but I have changed the #define so that I am NOT using the random nonce. I see join requests with incrementing nonce numbers, but when I reset the device, the nonce goes back to 1. I've put breakpoints in the code where I think it should be storing out to flash, but they are never hit.

My code is very closely based on the endpoint example.