Hi guys,
We have a LoRaWAN device that is using ABP.
We have created an application, where we added the device and set:
We can see data coming from the device in the gateway, but it never gets routed to the application. In the gateway we can see the following:
Any help will be highly appreciated!
/Szabolcs
’ If a manufacturer puts fixed DevAddr/NwkSKey/AppSKey in a device without giving the customer the ability to change those, they either don’t know what they’re doing or they don’t really care about the customer or they try to create some kind of lock-in to their own network.’
all TTN device addresses will start with 0x26 or 0x27 if not they are 'dropped and that’s what you see
Thanks for your response.
What can we do in this case, to receive data from the sensor?
Change the DevAddr to something with 0x26 / 0x27 or switch over to OTAA?
ask the manufacturer … but I think in general that devices with fixed DevAddr/NwkSKey/AppSKey are useless
Dear BoRRoZ,
I am representing the manufacturer in this case. This is just second time we work with customer using TTN therefore please apologize my maybe not well educated questions.
For this specific devices we have bought our own prefix from IEEE (4.5 bytes) and we auto-generate the rest of the DEVEUID (3.5bytes) by incrementing.
DevAdr is always the last 4 bytes of DEV EUID.
Net and App keys are for the ABP mode autogenerated from the DEV EUID by our own secure algorithm.
We do this to make sure we are able to produce high amount of devices by sequence flashing of the devices at the production lines. To do manual change of DevAddr or Keys based on the keys generated by TTN server is simply not reasonable.
When it comes to “allowing” customers to change the keys and dev address, could you please advise how the other vendors do it? On other devices we have ability to do via bluetooth anything but there is nothing like that on this device.
Thank you for your advice in advance.
Martin
what device are we actually talking about ?
You cannot do that: the DevAddr should be assigned by the operator, not by the manufacturer.
A DevAddr as assigned by TTN will always start with 0x26 or 0x27, and for TTN the next bytes indicate other details such as the region; see https://www.thethingsnetwork.org/docs/lorawan/address-space.html Again, a manufacturer cannot assign those addresses.
Rather than hardcoding ABP details, a manufacturer could assign all details needed for OTAA though.
I think there isn’t anything to add to @arjanvanb’s answer. TTN’s official recommendation is to use OTAA unless you have an extremely good reason not to. If your devices are currently incapable of doing OTAA I would definitely recommend implementing that, it will save you a lot of trouble in the future.