DevNonce has already been used

[marekpow]

How do we manage this error?

I created an application CS v.4, and it started to work perfectly. I named this app with a space inside the name and suspected it might be a problem with integrating into InfluxDB 2. InfluxDB didn’t see data from CS. So, I deleted this app and created it again with the same parameters but with a name without any space in its name. From this time, the end device still sends the join-up links, but no join is accepted. I restarted concentrator twice but without any change.

I use CS OS 4.2.0.

[marekpow]

Yesterday, I did several actions on my RPi, so thanks to this, I finally had a working set with integration to InfluxDB 2. Great.
I ran the power-off command, and the command was executed. Great. I made a power-off on my RPi. Great.
I made a few improvements to the code of my end node (WIO E5 Mini) and downloaded them to the end node. No problems at all. Great.
I went to bed and slept silently.
This morning, I powered on my RPi and watched frames and events on my application. Gateway couldn’t respond to a join request. But nothing changed during the night. I made several reboot actions. Nothing changed. The keyboard didn’t respond after the “no DMA platform data” message on the gateway screen. So I powered off the machine and powered it on. The keyboard responds now, but the machine still can’t respond positively to this uplink message (the same message DevNonce has already been used). The last seen column shows that communication between an end node and CS OS stopped at 2023-12-21 23:21:45.
I think it is not worth fighting with CS OS 4.x further. I will wait for better times. Now, I’m going to return to the version of 4.1.1 CS OS. It ran ten thousand more stable than the 4.2 version. Of course, there is an error in updating integration to InfluxDB 2, but I can manage this bug. Sorry, Winnetou.

[sp193]

If you’re very sure it’s an issue with the Chirpstack OS, do carry on. But I’ll like to explain how the DevNonce works in the joining procedure.

During each and every join request, there is a nonce generated (a single-use token) by the device. By the LoRaWAN specification, the LoRa Network Server (LNS) is supposed to keep track of the DevNonce values used by the device. If the DevNonce value is already used, no response to the join is issued.

In earlier LoRaWAN specifications, the number is randomly selected. In LoRaWAN 1.0.3, it became a sequential value. A good device will avoid choosing the same DevNonce values over and over, but this really depends on the implementation of the device. This also means that the longer the device is in use, the fewer and fewer DevNonce values are available for use - until we re-activate the device in Chirpstack.

Personally, I think that this error is not the real problem, but just a symptom of the problem which you really encountered.

[marekpow]

Thank you for your reply. But I have a question. What do you mean when you say: “until we reactivate the device in Chirpstack.”. My end node, WIO E5 Mini, has stopped working. I tried different methods that should reactivate the device, but the device didn’t respond with the expected result. I have the CS concentrator in the version 4.1.1. I tried rebooting, shutting down, resetting the queue, flushing the queue, and removing device_nonces from the table device_keys, but the device still sends the join request, but the concentrator doesn’t reply with the join accept message. I choose the 1.0.1 version of the Lorawan protocol in the device profile. How to check which version of this protocol WIO E5 MIni supports? Is there any AT command to check this?

[sp193]

The process’s name is confusing. But what I mean here is to deactivate and activate the device, from its profile page in Chirpstack. This isn’t related to the physical device. Taking this action should get Chirpstack to delete all the session data (in Redis).

Regarding the version of LoRaWAN that the device is compliant with: you will have to refer to the device’s documentation. It is possible that there is some AT command to get the version numbers. But I think that 1.0.1 is very old and it is likely either 1.0.2 or even 1.0.3. I’ve started working with LoRaWAN in 2019, and 1.0.2 was already in use for a very long time. Anyway, the differences are mostly about the MAC commands supported, so it shouldn’t affect the ability to just join the network.

[marekpow]

I can’t reactivate. Page is disabled.

[sp193]

It looks like the device did not join successfully; this can only be done if the device has joined before.

Have you checked the Events tab, to see whether the LNS rejected the join request?
You wrote that you deleted the application before, so it implies that you deleted the device too. Have you checked that the region, EUI and keys were re-entered correctly?

[marekpow]

Even if I had accepted join message, then this page was disabled. In my opinion, this page shouldn’t be disabled ever. I should have to be able to reactivate the concentrator at any time in the context of the end node.

[marekpow]

I think my RAK 5146 concentrator was partly destroyed. It’s the conclusion of my problems from the last few days. I tested the 4.20 version of CS a few days ago, and I can’t shut down RPi. I have to power off it without stopping it. This power-off destroyed the RPi, but I hoped the RAK 5146 wasn’t. But it was damaged too.
I can’t connect to the RAK 5146 with a brand-new WIO E5 Mini end device. I used AT commands to join it, but it answered with join failed. It’s strange because, at the same time, the LoraWAN frames in the application show that the CS accepted the connection!
The next odd thing is that the CS gateway stopped displaying my location on the map. I can join the same end device to the TTN without any problem and send uplink messages to it.
So I’m sure I have to buy a brand new concentrator.

[sp193]

I believe the logic is that there’s no session data (thus no data to destroy) if the node never joined before, so there’s no option to reactivate the device under such circumstances. That button is not about clearing data related to the LoRa gateway, but the session data (e.g. frame counters, MAC command states) maintained for communicating with the node.

If you were looking at the LoRaWAN frames view for the LoRa gateway, you can see frames appearing from every LoRaWAN node in range - even from nodes that do not belong to you. But if you saw frames in the LoRaWAN frames view for the node itself, then the messages there do indeed belong to your node.

---

Before concluding that the RAK5146 is faulty, have you attempted eliminating the problem through substitution? Like replacing the RPi’s power supply, microSD card, replacing the HAT if you got another board, rolling back to the earlier version of Chirpstack Gateway OS (if that worked before). I suppose the RAK5146 is one of the more expensive components in your system.

I have used the RAK5146, but not with the RPi and also not with the Chirpstack Gateway OS. It’s a mini PCIe board format, so you must be using some adaptor to connect it to the RPi. The RAK5146 would be connected through either SPI or USB (likely as a USB to SPI adaptor), which are external busses - which I think should be less likely to cause a computer to hang. Rather, I think it is more likely for it to just not operate properly.

---

As for location, the LoRa gateway may optionally have a GPS. The RAK5146 does, but you need to have the GPS antenna connected to it. The interface for GPS feature of the RAK5146 must also be connected to your RPi and the packet forwarder (Chirpstack Gateway OS in your case) must be configured to use the GPS. I have never used the Chirpstack Gateway OS before so I cannot advise you on what to check, but the path to the NMEA device (some serial port or a device named “/dev/nmea”) could be configured for the standard Semtech packet forwarders (e.g. UDP packet forwarder or the Semtech BasicStation).

It is possible to cat the GPS device (e.g. cat /dev/nmea or which serial port it appears as), to see whether the NMEA messages appear. From the NMEA messages appearing, it is possible to tell whether the GPS can get a fix or not (e.g. from xxRMC). The GPS getting a fix, depends on whether the GPS antenna has a line of sight with your sky.

Since you seem to have seen it work before, it must be supported on the hardware level of what you are using.
For me, my RAK5146 was plugged into a mini PCIe slot of an industrial PC. But because there’s no support for the pins where the GPS is connected to (in the mini PCIe), I could never use it.

Good luck!

[marekpow]

Thank you for your reply

I have changed RPi to the 3B versison. And CS to the 4.1.1 version.

I have a GPS antenna on the RAK 5146 device (and it worked a week ago).
Now I get a message when I click “Set to current location.”

But my location started automatically on the map when I configured the gateway a week ago.

I have changed devEUI and AppEUI to set actual IDs, not leaving them filled with zeroes as the code documentation states. And I have the working set for now.

But I see a strange situation now. What does it mean?

And again, the activation page. As you can see, I have this page disabled even when I continuously receive uplink messages.

[marekpow]

And the end

I returned to the beginning of this topic. Worked, worked, and finally dead.

Reactivate the device button is disabled because all activation pages are disabled. What should I do to leave this deadlocked state?

I clicked on the boot and reset button on the end device, and now I have such a situation:

I didn’t do anything…

[sp193]

If you’re looking at the node’s profile and the Activation page is always greyed out, I have no idea. Sorry.

---

Regarding the error you got when you clicked on “Set to current location”: I suppose it means that you’re accessing Chirpstack’s web UI via plain HTTP, which is no longer an allowed thing by Google when it comes to using their maps service.

---

Regarding the OTAA ERROR-level messages: are they from one device or many? If you left them alone for a while longer, do they eventually join? You may need to study the data inside the database or maybe from the device level.

Chirpstack seems to log something like this that also includes the DevEUI and DevNonce, whenever a DevNonce value is recorded. It does not seem to log rejected values. But maybe if you repeat this cycle of clearing the DevNonce values & letting the devices join again, some pattern may be observed from this message?

Device-nonce validated, join-nonce incremented and stored

What seems to be unclear to me, is whether these devices are indeed somehow reusing the DevNonce values, thus the errors. Or if Chirpstack somehow just spewing out those errors for each and every join attempt, regardless of the DevNonce values selected by the device.