Some vendors re-use some codes across device types (typically the Join EUI aka (previously) App EUI) but having both shared, I think is unusual…I trust you have double and treble checked your own reading and typing of the codes ;-). Application name might have been a clue but none of the users with Jeroen as part of their user or proper names has been seen on the Forum for >3 years that I can tell so unless contacting all of the other users in turn to check it may be a challenge. (That far back would have been under TTN V2 rather than V3 (TTS(CE)) so effectively dead devices now unless migrated since. You cant get it removed - it would need to be TTI core staff (post to #support on Slack)… even then the other users might be legit and were there 1st so some investigation needed before blind delete!
What is your Join & Dev EUI? (They arent secret - get sent in the clear on OTAA join request!)
It’s the Dev + Join EUI combo that has to be unique for there to be an issue with TTN which has many many users, some with finger/typing issues, some with device vendors that don’t look too hard at what they are doing with EUI’s etc and occasionally devices are returned to resellers which are sold again.
This isn’t an ideal situation - you could ask the supplier if the device has prior history but mostly if you post in the support channel on Slack with the details it can be resolved - but please consider that we don’t pay for even using the servers let alone get one on one support and this is not a situation of TTI’s making, so it may be a few hours before anyone can address this for you. Here’s a Slack join link:
Alternatively, you could check if you can set your own Dev or Join EUI for the device, if so, you can generate one on the console when you register the device.
I’m not trying to invoke paranoia, just want to understand how this can happen. Many vendors seem to be using static and publicly known JoinEUIs. So if people mistype (by accident or on purpose) their DevEUIs for this vendor (the JoinEUI being static), we can easily end up with illegitimate registration of devices blocking legitimate owners. Is this not correct?
IMO it would make more sense to require a successfully joined device, i.e., proof of the correct application key before blocking other users. The application key is the only thing considered random and secret.
Thanks for your suggestions and the Slack link. I will follow up on Slack and with the supplier, if the device has a history.
Potentially getting closer, but I’m unsure what you mean by JoinEUI being static so bit hard to say. And a device may not ship with a JoinEUI or an AppKey, or if they do, a fair few devices allow you to set your JoinEUI & AppKey and sometimes even override the internal DevEUI so a join by a device isn’t really much in the way of proof.
I guess the 20635F000A000013 could imply something in terms of the 000A being a product id and the 000013 being a batch number. Or something like that. So there may be a whole pile of devices around with that JoinEUI and a running sequence from 20635F0161000000 onwards. I use a scheme that tells me who the device belongs to, what it’s for and other info, plus a JoinEUI that is per customer application but wasting four octets on a random number so this issue is unlikely to arise. If I was selling through distribution or retail, I’d go as far as removing the B’s as they get confused with the 8’s as the typical mis-reading. Although providing a claim mechanism would probably be simpler and save typing lots of digits.
But to stoke the paranoia, sure, give me ten minutes with a script and I can create mayhem across the network with some of the product shots on here and else where, plus registration info on the IEEE database plus products I’ve purchased which allow me to see what patterns arise.
Give me a few hours and the script could extend to sending join requests. A half day I could have a batch of devices actually sending uplinks. Give me two days more and I could have a batch of devices rotating EUI’s & keys and sending every few seconds, thereby looking like many thousand potentially legitimate active devices.
But whilst he’s shorter than me, incurring the wrath of @adrianmares who’d end up having to purge that little exercise in community sabotage isn’t on my To Do list for 2023, because, yes, I am afraid of him.
I think the best reason why hijacking EUI’s isn’t at thing is that there’s not much way of knowing who’s going to get what device when so unless you do it in bulk as suggested above, all a bit academic.
And no one mistypes on purpose when registering a device as it would never be of any use - their purpose would be to block someone else’s registration, but they don’t call me @descartes with that sort of thinking for nothing.
The vendor is Abeeway, and the same JoinEUI is used for at least two different products, the Compact and the Industrial tracker. From the devices I received, one is manufactured in 2020 and the other appears to be more recent. I take from that that they are probably using the same JoinEUI across a wide variety of their products and batches, if not for all of them. AFAICS, there is no (publicly documented) way to change either the JoinEUI or DevEUI of the device. That’s what I meant by ‘static’.
AFAIU, there is no technical barrier from claiming DevEUI/JoinEUI combinations and DOSing others (be it by accident or on purpose), but organizational measures in terms of relying on TTN/TTI staff to remove devices and/or accounts that are misbehaving. And it rarely happens, as there is not much to gain from it.
Anyway, I just wanted to be able to use my device on TTN Thanks again for the discussion and the link to the Slack support, this should get it resolved.
For clarity for anyone else reading this as Ms Google does love to index this forum, this is not unique to TTN/TTI - any & all providers of a LNS would face similar challenges.