I’ve been trying to migrate a couple of basic test apps from staging to console
I’ve had no luck getting a device to connect in the new console environment.
I’ve been through the staging app and deleted all references to the device. When I try to connect this device I get this error message in the TTN console:
“Activation DevNonce not valid: already used”
We used the device in a student workshop a couple of months ago. Is it possible that it is still registered in an account that one of our students setup on staging? How could I verify this is the problem? How can I remove all references from staging?
The good news: If the console shows the error, at least we can be sure that you registered your device correctly, so no problems there.
The bad news: it seems your device does not follow the LoRaWAN specification. When a device joins, it must use a unique DevNonce (usually random works fine). When it uses a DevNonce that was already used before, you see the error “Activation DevNonce not valid: already used”. I recommend you to check the firmware of your device, as this will probably be the problem. As the Handler keeps a list of used DevNonces, deleting and re-registering the device might also work (but it’s not a solution to the underlying problem).
Thanks for your post… was helpful in tracking down the cause of issues with DevNonce not valid
My experience…
I have two test sensors (arduino, shield, mdot) each of the two mdots was flashed with the same firmware.
I had setup two applications each associated with a different device. The first ‘joined’ without issues. On creating the second, the device could not join as the DevNonce already used. I deleted the second app and recreated it but the DevNonce issue remained.
I deleted the first app and device… (short pause)… the second app and device then joined without issue.
Q) if the DevNonce is a ‘randomly’ generated 2 bit number - is it bound someway to the firmware and is there a configuration step which addresses this concern?
(using v2 console - all apps in v1 staging deleted)
DevNonce is a random value.2 For each end-device, the network server keeps track of a certain number of DevNonce values used by the end-device in the past, and ignores join requests with any of these DevNonce values from that end-device.
2 The DevNonce can be extracted by issuing a sequence of RSSI measurements under the assumption that the quality of randomness fulfills the criteria of true randomness
Peeking into the code seems to confirm that the nonces are indeed registered per application and per device. So, devices should not affect each other.
The handler uses the application id and device id (not the DevEUI) to store the used values. Any chance you can post the Join packet? Then we can see what DevNonce is used (even though I fail to see how it could affect anything, especially as for you they even belong to different applications). Do you happen to use very long application ids or device ids, or are using non-ASCII characters?
I’m using mdot modules with arduino and a shield, seemingly similar architecture to enarcee. How would I go about checking the firmware and what should I be looking for?
How can I retrieve the join packet to send you? would the at&v report contain the information you need?
The application ID I use is simply the one supplied by TTN (16 digit HEX).
The device EUI are 16 digit hex as well
The device ID’s are less than 8 characters (ascii) no spaces.
I’ve no idea what “the at&v report” is, but it would be something like a Base64 encoded ANwAANB+1bNwHm/t9XzurwDIhgMK8sk=, or maybe some HEX value. Gateway logs might show it…
My above remarks about those values were for @enarcee, as they have multiple applications/devices and removing one application/device solved the issue for the others, while those should not have affected each other. For @LawrenceM all we know it might indeed be non-unique nonces. (My bad for using the wrong “Reply” button?)
Also, it was about the Application ID that you can choose yourself. While the AppEUI and DevEUI are indeed the ones to configure in the node, TTN uses them to first have the Network Server enhance the activation, and then the Handler uses the Application ID and Device ID that you can choose yourself to find the device and to check the nonces. That seems solid, so I was hoping that some oddity (like very long self-chosen ids) might be the culprit…
@enarcee, did the problems return when adding the first application again?
Thanks Arjan
Things have progressed a little since I last posted. With no apparent changes from me I can now sucessfully join the network. TTN’s read out is as below
Beware that your log is not sorted by time correctly…
If the log is for one node: is it really joining twice? And are you really receiving data after the 18:33 error?
At first I thought that the first Join Accept response was not received by the node (TTN cannot know that, so shows “Activation” at 18:30), after which your node repeated the very same join request (at 18:33), rather than creating a new request. However: the node seems to be sending data (at 18:30, after the first join; but weird that both say “retry”), so it must have received the secret keys from the Join Accept message, so there is no reason to join again?
Any chance you can check if your node really tried to join twice? (You’ll need to peek into the logs of your gateway.) If received by multiple gateways, then I cannot imagine the 18:33 request is the same as the 18:30 one, but 3 minutes late. Something is repeating things though.
A workaround from @htdvisser on Slack, if you really need to clear the nonces that TTN has stored:
The backend clears the DevNonces when you change the AppKey, so if this is a problem, you can just change the AppKey to something else and then change it back
Thanks Arjan I followed the links regarding trying to access the join packet from the gateway. I’m not really sure how to run the functions that you have linked me to.
[quote]
(You’ll need to peek into the logs of your gateway.) [/quote]
I don’t own nor have physical access to the gateway, would this be required in order to peek into the logs?
Interesting point about the out of order timestamps on the log. I can confirm that I continued to receive data on TTN after the 18:33 error.
I have the same issues. I see repeated activation requests of different repeats until it starts sending real data. Always when I unplug my node and power it up again, it may work or not.
I have a LoRa node and do my tests with that node only, my other LoPy is a nano gateway running on power supply.
The node was running using a USB power bank (Anker Power Core 21000) and that runs out of power soon or later
(So in my tests from yesterday until now for a longer burnin test or how long runs it with a battery test)
Is the issue known for these type of nodes (and firmware)?
Should I report that to PyCom?
When the RSSI values are used for randomnes, and I do not move the node, may it more likely, that the values are the same and thus used before? If so, then this is not true randomnes until I move the node. What I mean is I cannot move a node in the field. I would expect in that case the join would take very long (what I have seen).
In that case, I need to ensure uninterruptable power supply
AFAIK the LoPy has no issue with nonces, the problem is OTAA activation is very time critical (particularly on TTN, where the Join accepts seem to be sent to gateway with less a second left until it’s needed ) On the other hand on the current Nanogateway code the downlink timings are more relaxed than ideal.
The result is the LoPy node misses the Join Accept response message and thus continues to try to join.
Was there ever any resolution to this? I’m seeing this A LOT using Marvin boards with Microchip LoRa modules on 0.9.5 firmware. I change my code (Arduino IDE), load it, and go.
The workaround of changing the AppKey does help, but only for a while. Eventually, it seems to reuse the same nonces and joining becomes difficult again.
This is in a development environment at the desktop, with the gateway several feet away. @lollisoft mentioned that, in close proximity, the RSSI might be consistent enough that the same set of pseudo-random numbers keep coming up. In the field, I would expect a far wider range of RSSI values.
…and you might be able to kind of automate that using the command line ttnctl?
I don’t think there is any resolution, except for upgrading to LoRaWAN 1.1 for which if I recall correctly (confirmed) the nonce is an increasing counter rather than a random value. But then I think the device needs to keep track of the last used counter value… (But I might be wrong.) Also, that needs TTN to use its V3 stack of the network software, which is not available yet.
So… keep changing the AppKey during my development cycle and then hope that the device doesn’t have to re-join often enough that this becomes an issue
THANK YOU for the suggestion of ttnctl! I had been wondering whether TTN had some kind of API to control some of these things. I’ll give this a look and see if I can get that to do what I need. If it will, it should be a simple fix to store the current AppKey, change it, and set it back to the original value.
