ecosoph
(Markovicz)
February 21, 2021, 4:42pm
1
Hi Guys,
I’ve noticed that there’s no option for auto generate AppEUI and DevEUI in thethingsstack v3 anymore (as compared to TTN):
To be honest, I don’t have so much glue so I needed to google a bit to find related threads:
Hi,
When buying a commercial node, how can you register it on a network ?
I understand the keys (DEVEUI, Apsskey and Appeui) must match the server side.
Does a device manufacturer needs to label his device with these 3 keys ? Or is just the DEVEUI sufficient ?
How do the remaining keys match ?
Thanks!
opened 10:50AM - 20 Jan 17 UTC
closed 12:39PM - 03 May 17 UTC
feature
c/backend
This is a **feature request** for **the Backend**.
Currently, only devices th… at are registered can be accepted when joining the network. This requires all devices to be known, including their DevEUI. This might not be practical in large scale deployments.
Therefore, it should be possible for devices to register on join. To avoid join challenges to be sent to all Handlers that registered the AppEUI with a Broker, there should be a first-come-first-serve registration of AppEUI. We might leverage the current unique registration of AppEUI/DevEUI but then with a blank DevEUI. If the Broker doesn't find a specific AppEUI/DevEUI combination for the join, it can challenge a Handler that has the AppEUI registered with a DevEUI as catchall.
## On Security
When allowing any DevEUI to join for an AppEUI and the AppKey leaks, we basically enable spoofing of existing devices and registering new devices. This means that the application needs its own mechanism to identify the device. Many IoT platforms already support this with a device registry. Also, when introducing this feature, we should inform the application owners of the potential risk.
Also, we should restrict the AppEUIs that can register devices anonymously to a range in the Foundation's EUI block. Otherwise, people can abuse The Things Network to send conflicting join accepts for any join request as AppEUIs are public. We can configure the Brokers with an environment variable for a range.
Custom RF95 hope solution: HopeRF RFM95 and arduino a low cost LoRaWan solution - disk91.com - the IoT blogdisk91.com – the IoT blog
What is the recommended procedure for adding a custom-built LoRa device using OTAA to v3?
Thank you a lot!
EDIT: I’ve digged a bit further:
One solution could be buying cheap ICs from e.g. farnell with a EUI-64 identifier from what I understood:
https://de.farnell.com/microchip/24aa025e64t-i-ot/eeprom-2k-256x8-1-8v-seriell-6sot/dp/2345565?st=eui
kersing
(Jac Kersing)
February 21, 2021, 5:32pm
2
That is certainly the best solution if you only need small amounts of EUIs.
However if you searched this forum a bit you should have found this question popped up a few weeks ago and the pragmatic solution for now is to use V2 to generate EUIs and use them on V3.
ecosoph
(Markovicz)
February 22, 2021, 7:13am
3
@kersing the v2 generated EUI came up to my mind as well somewhen yesterday after posting this question. I did some forum search but couldn’t find it. Sorry for the spam.
Really?
A simple search for DevEUI would have shown the following in top of the results:
When adding a new device in the V3 Console it is currently not possible to generate a new DevEUI.
This is a known issue . Generating new DevEUI will be added in a new release .
(The DevEUI is actually not generated but will be issued from a valid range of DevEUI.)
The DevEUI is required for adding a new device to a V3 application.
Existing V2 devices will already have a DevEUI but many new (DIY) devices will not.
As workaround a temporary device can be created in the V2 console and then copy …
ecosoph
(Markovicz)
February 22, 2021, 10:11am
5
@bluejedi alrighty, sorry! Shall we lock or delete my thread?
1 Like