DevNonce changes in 1.0.4

[BNNorman]

I'm reading this:-

https://www.thethingsnetwork.org/forum/t/lorawan-1-1-devnonce-must-be-stored-in-a-non-volatile-memory-on-end-device/48995/4

And in particular this

This is telling us that DevNonce is no longer a random 2 byte number but an incrementing number which has 64k possible values. A random number can be repeated.

Do you plan to change the dragino.py code? It will need to store the devnonce (probably in dragino.ini) and increment it on each join attempt till it reaches it's max value. One hopes that 64K values is more than enough for testing.

I'm hoping this is why my dev code is only occasionally showing a join-request in the V3 console and making dev difficult.. I'm about to test that today.

[pjb304]

It could be - I'm running my nodes in 1.0.2 MAC and PHY so it's still valid - however, if you're running on a more up to date version, then it might cause issues.

[BNNorman]

I take the view that [0,1] , [0,2]...[255,255] are all valid random devnonce values. I don't know if 1.0.2 MAC checks them other than I know TTN rejects join requests with repeated values when sent .

I have temporarily added a 'getDevNonce()' method which sets self.devnonce , increments the last value and stores it in a file imaginatively called , ahem, devnonce. This is called in the join() method. But I still haven't succeeded in joining on V3 so I'm about to see if I can create a single channel gateway for testing. Some joins have been accepted but I haven't received the downlink - could be RSSI with the gateway being 11km away.

My use case is investigating adding LoRa capability to roadside speed signs for my local council. Currently they send a bloke with a PDA to download the logs via bluetooth. Its quite complicated to stay within Fair Use policy and 1% airtime regulations. The signs would be in urban areas and likely have trouble with joining hence my test program tries all join freqs and SFs. No success yet.