Hi all
my device (OTAA) sends JoinRequests. I can see the traffic of the join in my gateway.
Other devices (different vendors though) work.
I did compare the IDs several times, so I’m pretty sure that all IDs are correct.
Is there any way to see WHY there is no Join Accept coming from the network server?
E.g. device does not exists, wrong MIC, … in some log or is there another hint?
In the TTN console, do you see packets in the application data? If so keys match. If no join request shows in the application and the requests are visible in the gateway data your keys might be in the wrong order (lsb/msb)
Another possibility is issues where the gateway is registered in one TTN zone and an application in another (for instance gateway using us-west and application using eu). Traffic sometimes disappearing in those cases is a know issue.
Hi Jac,
thanks for the answer.
Ok - no data in the application data (I can only see the join request in the gateway data).
So wrong order (I will check again MSB/LSB) or wrong MIC (which one can check using the payload data).
Each network (should) keep track of the DevNonce’s a devices has used. But networks do not know which were used on other networks. If the DevNonce is random, and you’ve not done a lot of joins on TTN yet, then even if one attempt is rejected, chances are that the next is accepted. Also, one can reset the list; see OTAA shows "Activation DevNonce not valid: already used" - #13 by arjanvanb.
If you cannot force a new join (like by removing the battery), does this imply the device is not close to you, and you only checked and re-checked the DevEUI, AppKey and AppEUI in TTN Console?
You might want to get an MQTT client running, subscribing to all events, to capture as much debug info as you can.
I can touch the device but there is no option to send a join request - removing battery …
But I think the vendor has to add something at least for installation purposes during a bigger rollout.
Right now we are just testing so that’s not a huge problem - at least if the device would work .
Unless the manufacturer confirmed this: such bug would be something that surely the manufacturer would have noticed during testing?
So, the DevEUI and AppEUI as shown in the decoded Join Request (in the gateway Traffic page in TTN Console, or in the online decoder) are an exact match with the values you entered into TTN Console? And did you try to reverse the AppKey in the online decoder, to see if the MIC validates then?
Some screenshots might help to confirm that what we think you see, is indeed what you see. Only the AppKey is secret, you could redact part of that.
Right. But you do know the AppKey, right? In the online decoder, you can paste that into the field for AppSKey, and set some dummy for NwkSKey, which is not used for a Join Request. If you get a failure, then try to reverse the bytes in your AppKey (when entering that in the field for AppSKey), like enter 112233 ... EEFF as FFEE ... 332211.
Okay… For future reference, to save others some time, can you please add some details about the device brand/type/…?
And just to be sure, as I find it hard to believe a vendor would not have noticed a bug: the AppKey you’re using is really labelled as such in some documentation, right? Like for LoRaWAN 1.1.x, terminology has changed, but a 1.1.x device should be backwards compatible with 1.0.x (TTN community network uses 1.0.2). Maybe it’s just the documentation that’s wrong…
That depends on your device and the LoRaWAN software stack you’re using on that device.
Your screenshot shows the gateway’s Traffic page, which apparently has received the Join Request. In that Traffic page, the AppEUI that the device has sent looks okay. (Given the first characters you’re showing, this looks like a TTN-assigned AppEUI, which start with 70B3D57ED.) In that same Traffic page you can also validate if the DevEUI in that Join Request matches what you see in the Device Overview page in TTN Console.
To ensure the secret AppKey was okay too, look at the device’s or application’s Data page, which should show an Activation (orange icon) and a fresh DevAddr each time TTN accepted the Join Request, hence: if all of DevEUI, AppEUI and AppKey were okay. (Note that you need to have that Data page open before the Join Request comes in.) Or look at the device’s Status, which will change from “never seen” to some timestamp whenever a Join Request has been successfully accepted.
Or, in your case, the DevEUI, AppEUI and secret AppKey that you used in the online decoder did indeed match the values that the device used, as the calculated MICs match. So, if you copied those values from TTN console into the decoder using the clipboard icons, without explicitly changing anything to LSB first, then all of the DevEUI, AppEUI and AppKey in the device are okay.
If you do see the Activation, but no Join Accept: note that TTN might have selected a different gateway if the Join Request was received by multiple gateways. Click the Activation to see which gateway(s) received the Join Request.
Your last post shows ABP in the Device overview in TTN Console, but also an OTAA Join Request. You’ll need to change both the device and the settings in TTN Console when changing from ABP to OTAA or the other way around.
For ABP (which is not in scope of this very topic, as there is are no Join Request and Join Accept for ABP), program/configure DevAddr, AppSKey and NwkSkey, to make the settings in the device match those in TTN Console.
For OTAA, you’ll need DevEUI, AppEUI and AppKey to match. For this, the matching MICs in your screenshot of the online decoder already showed all was fine, assuming the same values were used in the device’s configuration in TTN Console. So: did you copy the values from TTN Console into that online decoder? (As you’re not seeing an Activation nor any error, I’d assume you copied the values from the device, not from TTN Console?)
Aside: only the keys (AppKey, AppSKey and NwkSKey) are secret, which is why TTN Console won’t show those until you click the little “eye” button. (You can still use the copy button though.) The AppEUI, DevEUI and DevAddr are not secret. Also, whatever is shown in the gateway’s Traffic or device’s Data is not secret.