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
I would be very interested to know which LoRaWAN library you are using on your Heltec device, because I don’t know of any good one that supports LoRaWAN v1.0.4 with this very persistent DevNonce issue. Heltec’s own LoRaWAN library uses v1.0.3 anyway.
Yes I know, but do those support the Heltec CubeCell? RadioLib sort of does, but good luck running it for a full day - I’ll be happy to hear if you succeeded
I hope not, but I’ve tried it on CubeCell myself and haven’t had much luck. CubeCell is just too old at this point, and especially it’s terribly bad clock is much worse compared to other microcontrollers.
omg I didn’t know that and decide to use cubecell’s in my setup because of their very low power consumption in sleep mode. this is most important thing for me.
any advices for another MCU + LoRa with 2-3 GPIO for external sensors?
Quite depends on how dirty you want to get your hands. There are the new Heltec boards based on ESP32-S3 - with quite a bit of care, you can get them down to 20uA (although only on timer wakeup, not on GPIO wakeup). They’re a primary citizen of RadioLib (all my development happens on Heltec-V3 boards), so at least you’re guaranteed of a usable RadioLib.
Another option is to use an ATmega or SAMD chip combined with a Wio-E5: a bit more challenging probably, but should also be able to go down to the 20uA region. Advantage is that you don’t need to care about any LoRa stuff / RadioLib, as the Wio-E5 does it for you.
And the hardest but lowest power option one is an STM32WLE5 module (e.g. LoRa-E5); depending on the board you get it can go down to single-digit uA, and it can run RadioLib (the HAL for that is not in the repository yet, but will be in a few weeks likely). Or run it through STM32duino, but that has limited options and may not get you the lowest power.
The difference between the two is that on TTN you can toggle a checkbox such that it always allows a reset, while on CS you have to hit the Reset button each and every time.
