I have a RAK7243 gateway. TTN Console is showing the gateway as connected, 133 messages received, last seen a few seconds ago.
I have an Application defined with three LoRaWAN devices.The devices show as never seen in the Applicaiton --> Devices list and detail pages in the TTN Console.
Watching TTN Console Gateway Traffic I see ongoing “Join” traffic from each device about every 10 minutes. The Device EUI shown in the Gateway Traffic matches that printed on my physical devices and matches what I have configured in the Devices attached to the Application in the TTN Console. The only way I am determining they are “Join” messages is by filtering the Gateway Traffic - when I deselect “Join” the Gateway Traffic list is empty.
So, the devices appear to be talking through the gateway to TTN with respect to “Join” message but that is not being successfully matched with the Application EUI and devices within.
In TTN Console, clicking an item often reveals more info too. So: click! An OTTA Join is a two step process: an orange icon in the gateway’s Traffic page is an OTAA Join Request uplink, a green icon is a Join Accept downlink.
If you don’t see the green icons then look in the application’s or device’s Data page, or the device’s “Last seen” time. If you don’t see any orange Activation there, or no recent timestamp, then TTN did not accept the Join Request, so the configuration is wrong: check AppEUI, DevEUI and AppKey. If you do see it then the Join Accept was probably transmitted by another gateway; the same search as above applies then.
In short, as you’re seeing “never seen”: you’ll need to check the AppEUI, DevEUI and AppKey.
This is the situation I have. Traffic coming in the Gateway Traffic is a Join Request (thanks for the tip to click it). No Accept. Device “never seen”.
The AppEUI and DevEUI do match. However, AppKey, some reading now suggests this needs to be stored on the end device. I am starting to think this is part of the whole “OTAA” process which I haven’t fully grasped. I can’t find any information on how to send this AppKey to the end device. Is there a generic way to do this or is this something Netvox the device manufacturer should have specific information on? (I haven’t found any yet). Their documentation doesn’t mention an AppKey (I wondered if they would provide one with it).
(Or, the device would need to give you a way to program it, but that’s just an extra burden for you. So, the manufacturer needs to give it to you, if it’s not already in some documentation. It should typically not be printed on a label on the device, as it’s a secret and people tend to forget to remove labels.)
I have sent an enquiry to Netvox. There is nothing in the packaging supplied with the devices to state an AppKey or similar.
I’ve put in the APP KEY value you pasted and so far no luck.
It is surprising all the devices have the same EUI. That EUI you paste is certainly the same as one of the types of devices I have from Netvox. It seems logical each device would need its own to be uniquely identified on the network.
It is an absolute minefield trying to find the right device, for the right region, for the right purpose, from a reputable brand. I’m wondering if I made the right choice with Netvox.
Wow, I just had my first ever Join Accept. But I am left wondering …
The device which accepted uses exactly the same AppKey and AppEUI that you pasted. How can I possibly know if the Join Accept is coming from my device or someone else’s from the same Netvox manufacturer? Surely there seems to be no way to uniquely identify different people’s devices? I must be misunderstanding something because that doesn’t seem viable.
It will be interesting to see when Netvox responds to my enquiry as to whether they quote the same AppKey as you pasted earlier.
Each device still has its unique DevEUI. The way TTN implemented OTAA in V2 (and hopefully in V3 as well) happens to use the combination of AppEUI and DevEUI to find a device and its application. Still: not good at all to use a non-unique AppEUI for multiple customers, I’d say. Also: it seems some have had problems registering such non-unique AppEUI, but others see no issues, like both described in the link I posted above.
Also, now that the secret AppKey is in the open, I’d say that their security-by-obscurity failed on them, and I’d consider all similar Netvox devices to be compromised. The OTAA Join Request is not encrypted, so anyone can get the DevEUI (and AppEUI, but well, we know that already) from the radio transmission, if one can fool a device into starting a new join. That by itself might be hard to trigger, but the DevEUI won’t be random; it’s just one out of an incremental range of EUI-64 addresses that they purchased, so one could also simply try to guess the DevEUI. A rogue device could then initiate a new join, which the original device is not expecting. After that the original device’s DevAddr and secrets (NwkSKey and AppSKey) that it got during its own join will no longer be accepted by TTN, effectively rendering it useless until it joins again.
Be sure to peel off any stickers that show the DevEUI from the devices…
I guess at this rate I would not be surprised if the DevEUI is not unique across all Netvox devices but I could be pleasantly surprised.
I haven’t found the AppKey for my other devices online yet. Netvox has redirected me to the reseller regarding my enquiry of what the AppKey is for my devices. I’m hoping I don’t just get the run-around as I need the AppKey or I have bricks. I have sent an enquiry to the reseller.
They might use the exact same software for each device, with the same hardcoded AppEUI and AppKey, but that software might still determine the DevEUI from some hardware. Like if the devices use an RN2xx3 for their LoRaWAN communications, then that component supplies a unique DevEUI for each Netvox device.
Above, I linked to Netvox’ range of EUI-64 addresses from which they derived the non-unique AppEUI. But if you paste the DevEUI into that same website you might find it was registered by another company, from some third-party hardware component used in the Netvox device. (That would be Microchip for the RN2xx3.)
So trying the very same AppKey for the other device types did not work?
If different, I wouldn’t be surprised if it still looks like the given 00137A 10 00000000 then. Like 00137A 0A 00000000 or 00137A 11 00000000 and the like…
Aside: I would return the devices and demand a unique AppEUI and AppKey.
I did try that last night without success but it seems I needed to reset the devices. You prompted me to re-try. I now have three of my four devices connected, using identical AppEUI and AppKey values. This is crazy. The fourth device has flat batteries so need to solve that first but seems likely it will work.
When hunting for the right device it stuck me how the process of finding a device for LoRaWAN was an absolute minefield. Now even more so.
I either need a way to re-write the AppKey or return the devices or find alternative devices, because for my purpose I’m just not happy with the lack of security. I have had the devices for almost a year, it’s taken that long (on and off) to get the RAK gateway then the devices working and go through that whole learning process. I suspect the chance of return is unlikely given the time frame.
I wonder if the supplier is going to tell you if the devices can be programmed using downlinks. It seems that might be supported, at least for some types. If you find your device(s) in that documentation then you could try with some non-destructive settings such as timers, if you get no help. But for AppEUI and AppKey you’d then need to be sure that those changes survive changing the batteries.
(Also, it’s weird to reprogram devices using downlinks, as that first needs a device to be joined, which is especially weird when changing OTAA to ABP using SetActiveModeReq. Those specific commands also say “(only valid in highdatarate )-----for CR2 CustomerSupport”. Oh well…)
The reseller has supplied a list of AppEUI, Appkey, DevEUI for my devices. I think it would be responsible of me to not elaborate on that too much in an open forum. As such I am asking them for information on being able to update the values to see what they recommend.