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.
In theory you can validate the raw join request yourself since you have the keys.
If it ever worked in the past, another possibility is that it is re-using a previously used join nonce, which will lead to silent rejection.
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).
Thanks cslorabox,
this (re-using Nonce) would mean that it worked with that network server not with a different one, right?
I’m guessing the devices were activated on a different netwok some time ago.
BTW, the Join Request comes only thrice a day, so kind of difficult to get/check the data.
Are MartinM and LinkeKlebe the same person?
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 
.
We are two persons working on the same PC. Sorry.
So, you got some DevEUI, AppEUI and AppKey in the documentation of the device?
The first two are not encrypted in the Join Request message, and you can easily see/validate that documentation and the LSB/MSB byte order in the Join Request in TTN Console. Or you can validate all three manually from the gateway’s log, while also validating the MIC using the secret AppKey.
Ok Thanks Arjan!
The MIC seems to be wrong - using the lora-packet library.
My understanding is that the device has a “bug” when calculating the MIC.
The initial question
is kind of solved. There is no way to see it in the TTN console directly but there are other methods available.
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.
Ok, makes sense what you write about a possible MIC bug.
Here the Request in the gateway
(Payload: AAkHAAAAAAAAk/ItAAAJBwDqAI9mnQ0=)
The device, which does not get any data
Here we get the MIC
but for checking the MIC you need the AppKey, right?
I used the lora-packet library (verifyMic) which failed.
So, DevEUI and AppEUI are looking good.
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.
Thanks for the check
Get failures for AppKeys (LSB/MSB)
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…
Oh, that was not a good example. Just to make sure you know that a byte is two characters (two nibbles) in hexadecimal:
Enter 102030 ... E0F0 as F0E0 ... 302010 to swap the byte order.
Hi,
Must Device EUI, Application EUI and AppKey be LSB or MSB? For OTAA
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 there’s still no Activation then ensure you’re not running into OTAA shows "Activation DevNonce not valid: already used" - #13 by arjanvanb.
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.
Hi,
Thanks.
I am using a Feather 32u4 EU868 and the Gateway is a Multiteck Conduit - EU868
The Feather 32u4 EU868 are configured on the ABP, but I have changed between the modes (OTAA and ABP)
I can see the join request on the TTN network on my gateway -
At the same time I do have the data page open but no data.
I can also see the device have never joined.
So I am at a loss of where to look for the issue.
Regards
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.
Hi,
Thanks.
The settings on TTN is for OTAA on my device, I were merely trying the ABP, as OTAA were not working.
I do use the “eye” button and the copy button to copy the (AppKey, AppSKey and NwkSKey).
So I deleted my device from the app and recreated it, recopied the keys and now we have success.
Thank you for your help.
Can someone also help me here, i am trying to connect node, but the join request is not being accepted. it often goes false.
