Im testing my heltec cubecell ab01 with different codes for send/receive LoRaWAN data - so Im restarting device many times.
and because of this I receive error “DevNonce has already been used”
im trying to get rid of this error by setting “Disable frame-counter validation” and re-activating device - but it doesnt help. after first joining and restarting I cant join again - Im receiving “devnonce” error.
is it possible to disable this behavior and have ability to re-join as many time as you want?
this is important for me because Im not going to implement Session persistence for some of my devices as they doesnt have onboard memory.
DevNonce is not f_count so disabling f_count verification will not disable dev_nonce verification. They are both used to prevent replay attacks, but essentially dev_nonce is the f_count for join-request and join-accepts, then after the device is joined it transitions to f_count.
I do not think there is an option to disable devNonce through Chirpstack, but there is the option on the activation page to “flush OTAA devNonces” perhaps you could use that for now.
While that might work as a workaround the real issue would be with your code, does the library you are using require/allow you to input the devNonce for joins? If so you want to ensure the devNonce increments and does not repeat, or else Chirpstack will decline it, assuming it is an attempt at a replay attack.
sure Im using this option for now, but I don’t want everytime press this button for flushing dev_nonce when my device restarted.
And I don’t want to keep this value in the device memory (some devices have no such memory chip) - so when it restarted it will be 0 and I want to configure CS that way so this device will join again without issues.
is it possible to do on CS? after all, CS is not TTN and we can use it as we want
Unfortunately I cannot speak to that, there might be, but I have never seen that option in Chirpstack myself.
I can think of two workarounds however:
One work around (still pretty messy) would be to use LoRaWAN 1.0.3, where the devNonces can be any number as long as it does not repeat. Then set up your device to just use a random number. Since your device cannot retain the devNonces it has already used, there is a chance that you use a number already used so you would still have to flush devNonces often, but it would let you get through multiple tests until you find a better way to solve this issue.
The second would be to use the Chirpstack API to trigger a FlushDevNoncesRequest after each join. Just create a simple bash script to subscribe to the MQTT broker, and whenever it sees a join-accept (or you could do join-request) have it flush the dev nonces. Similarly you could skip the API and just write a script to delete the used_devNonce section from postgres whenever something appears there.
Both just temporary solutions, but they would allow you to keep testing the rest of your system for now.
seems, there is 3rd workaround - use ABP instead OTAA… Im just reading about this and maybe it will work for my env… I just need send downlink messages very rarely and receive answers from devices, so it is really doesnt matter how they would activated
