Join requests receive but not accept

#1

Hello, I’m sorry in advance because I don’t speak english very well.

I search on this forum and lot of people got a different variant of this problem but I don’t find the good solution.

I made my LoRa Gateway (with this kit - http://wiki.seeedstudio.com/LoRa_LoRaWan_Gateway_Kit/).

This is the traffic of my Gateway
TrafficGW
We can see the join request of my 2 differents nodes but there is any join accept.

I see on another Topic this sentences :

This only tells you that it did not receive an OTAA Join Accept:

  • If TTN did not receive it, then of course nothing happened.
  • If TTN rejected it, it will not send any response at all. You will only see the orange Join Request in the gateway’s Traffic page (without a DevAddr).
  • If TTN accepted it and made one gateway transmit the Join Accept, then somehow the device has not received it. In TTN Console you will see both an orange Join Request Activation in the device’s Data page (now including a DevAddr), and a green Join Accept in the gateway’s Traffic page. Sometimes you’ll also see the orange Join Request in the gateway’s Traffic page. So, in TTN Console all will look fine then.

TTN not send any response at all and my nodes didn’t get DevAddr, so I don’t know how to fix this problem.

#2

AppEUI

Where did you get that AppEUI? It only shows 6 octets/bytes, but should have 8, but maybe TTN Console does not show leading zeroes? (DevEUI should be 8 bytes too.) If it was included with your device: did you add it to the application? If you have TTN generate one, then it starts with 0x70B3D57ED.

(Aside: in the linked post I erroneously used the wrong name for the orange icon in a device’s Data page; it’s called “Activation” there, not “Join Request” like in the gateway’s Traffic page.)

#3

I edited my image, with all my AppEui, DevEui and And DevAddr.
I found my AppEui on the web site of 1 of my node : http://support.nke-watteco.com/ttn-tutorial/

#4

Hmmm. That says:

  • Put the EUI 70 B3 D5 E7 5F 60 00 00 and AddEUI

So, everyone who owns such a device will be using the same AppEUI. (Aside: the first 3 octets match a TTN-owned EUI, which has fooled me earlier. But the remainder is different, and owned by Nke.)

I think off-the-shelf device makers should use a unique AppEUI for all their buyers, so use a unique AppEUI for all devices. So, assuming you also added that AppEUI to the application in TTN Console as shown in that tutorial (you did, right?), then you might be running into problems when another TTN user also owns such device: some users reported that as not being a problem, but others fixed that by using a unique AppEUI; see the link above.

But first: check, and double-check, that you copied the correct AppEUI (in the Application), and AppKey and DevEUI (both in the Device) into TTN Console. For the AppKey and DevEUI you should have some documentation with your device; do not copy the values from the screenshots in the tutorial. (You’re seeing the AppEUI and DevEUI that you should use in the gateway’s Traffic page. But you won’t see the AppKey there.) Maybe you’re lucky and the non-unique AppEUI does not matter as long as the DevEUI is unique.

Aside: the DevAddr you’re seeing is from another device. Only the lines with the orange icons (showing AppEUI and DevEUI) are for your device, the other lines are for other devices (and are not registered to TTN).

#5

AppEUI - It’s fine
ApplicationOverview

DeviceEUI, I write the code indicate on the device

DevEUI sticker

And I let TTN generate my AppKEY because I don’t know what I’m suppose to put here

#6

Well, there’s part of your problem. Of course, the secret AppKey known to TTN needs to match the one known to the device. You cannot just randomly set a value in one, and not have the same value in the other.

However, the Join Request is not encrypted. When receiving the Join Request TTN does not need/use the AppKey yet: given the AppEUI and DevEUI from the Join Request, TTN should be able to find the device, assign a DevAddr, and only then use the secret AppKey to calculate more secrets (the secret session AppSKey and NwkSKey) and create a Join Accept. So even with the wrong AppKey you should see the orange Activation in the device’s or application’s Data page, and TTN should select one gateway (maybe not yours, if multiple gateways received the Join Request) to transmit the (erroneous) Join Accept. As you’re not seeing the Activation in the device’s or application’s Data page (you don’t, right?), I’m afraid you’re running into problems as for your device the AppEUI is not unique, like described in the link in my previous post.

So, you need to find some document that gives you the secret AppKey. (Typically, that secret should not be on a sticker on the device, as people tend to forget to remove the sticker.) But that would still not explain why you don’t see the orange Activation in the device’s Data page.

Or, better yet, I’d ask the supplier: how to set/change the AppEUI and AppKey in the device? This way you can have TTN generate a unique AppEUI as well, and set the device to use the TTN-generated AppEUI and AppKey (and leave the device’s DevEUI as is).

#7

While the join request is not encrypted, the AppKEY is used to generate its cryptographic checksum.

Since the device is using an AppKEY unknown to TTN, the message looks like a valid join request to the network server part of the infrastructure, but won’t validate as a join against an application to the join server function.

Essentially at the first level:

“that looks like a join request”

and at the second

“well, that’s not MY join request”

It all comes back to the correctly identified issue of the AppKEY needing to be a shared secret.

1 Like
#8

But it’s not using that in the Join Request, is it? (Here’s an example.)

(Even more, when the erroneous Join Accept is received by the device, it will not even know that TTN used a different AppKey. Instead, it will just use the AppKey known to the device to derive the wrong session keys, and use those without having any clue they are wrong…)

#9

Ah, you’re right, it’s used for the MIC.

#10

It is using the AppKEY in the join request not to encrypt the message, but rather in that the cryptographic checksum (MIC) of a join request is calculated with the AppKEY since the network session key used for that with ordinary traffic doesn’t exist yet.

LoRaWAN is designed so that network and application level secrets can be separate layers of trust. As far as anything the network server knows, this could be a valid join request and gets passed on to the join server/component. But there, it’s found that the message does not validate against the only AppKEY known for that app EUI, because the AppKEY was mistakenly generated anew, rather than whatever AppKEY the device is actually using being found out and entered.

1 Like
#11

All is fine, thank you very much for your response, my node send a join request and my application send an activation request.
The off-the-shelf device makers send me the document with AppKEY and others authentifaction KEY.

#12

Nice. I still feel that the device should also have a unique (or user-programmable) AppEUI. So if you didn’t yet, I’d read the link I gave earlier, and:

1 Like