Generated Device EUI clashes with officially assigned EUIs

[tkerby]

I’ve been taking a look at what happens when you use the console to generate a Device EUI. It appears these are not unique addresses and are instead randomly generated. They clash with registered MAC address blocks and other EUI-64 addresses

This is a problem as they may clash with addresses in commercial devices or EUI chipsets.

A block of addresses is not particularly expensive. The smallest block at around $650 gives 250k addresses.

Could TTN buy some address space for devices? I’d happily pay £10 for 1000 addresses for devices that I could assign. It’s a much cheaper option to program device eeprom than have to buy an EUI chip

[arjanvanb (Arjan)]

Are you sure it’s not using one of the (deprecated) the algorithm for random local addresses described in DevEUI for non-hardware assigned values?

I’d happily pay £10 for 1000 addresses for devices that I could assign.

Nothing is stopping you, as normally you’d enter the DevEUI yourself anyway (as taken from the device), and assignment by the network is an exception. TTN did buy a block for AppEUIs, as those are normally assigned by networks.

DevEUI for non-hardware assigned values

The trick with free beer is usually that someone else pays for it.

For AppEUIs we solved this by buying a block of EUIs. Maybe we could crowdfund another block for DevEUIs, but it’s probably easier to just buy some cheap (less €0.30) chips that have an EUI. Just search for “EUI” on farnell.com

[tkerby]

Asking TTN to generate seems to generate globally assigned EUIs that belong to other organisations. Eg here is one I generated earlier by registering a new device: 0017020B5B65FFFA. The lower nibble of the MSB is zero indicating it’s a global address.

Looking it up, it’s owned by

Osung Midicom Co., Ltd
Seoul, Youngdeungpo-gu 150-832
KOREA, REPUBLIC OF
Range: 00:17:02:00:00:00 - 00:17:02:FF:FF:FF
Type: IEEE MA-L

That’s not good news if TTN is handing these out as generated Device EUIs.

The point I’m suggesting is that registering for 250k of EUIs is excessive for hobby type use and some means to resell small blocks other than buying chips to do it would be useful. It would be far better if generated addresses came from a genuine block

[arjanvanb (Arjan)]

It would be far better if generated addresses came from a genuine block

Of course, but like quoted from the topic I linked to: that’s not likely going to be paid for by TTN.

Wondering why TTN Console eventually has not used the suggestion for random local addresses though:

DevEUI for non-hardware assigned values

I think we have our solution. Thanks, @terrillmoore!

[tkerby]

That’s exactly why I’m suggesting ttn resell them through the store. By default, local addresses get generated but you have the ability to link your purchased block to your account and assign to a device.

We need a reseller as the blocks you can buy are too big and ttn could profit from the resale

[arjanvanb (Arjan)]

By default, local addresses get generated but you have the ability to link your purchased block to your account and assign to a device.

What’s the advantage of true EUIs over local ones?

We need a reseller as the blocks you can buy are too big and ttn could profit from the resale

I don’t see that happening either (if only as it already has been suggested in the topic I linked to), but I’d love to be proven wrong…

If the bright minds at TTN would only need half a day to enhance and test the shop, then profit quickly vanishes, even if they first sell parts of their existing block, currently used for AppEUIs. But worse: it would create a new problem of people entering made-up values if they don’t want to buy a DevEUI?

(Right now I’m reprogramming a node for which our provider boldly used all zeroes for the OTAA AppEUI. Yeah.)

@htdvisser, did TTN not use @terrillmoore’s suggestion on purpose? (Fixing the first bit seems to be an easy solution?)

[tkerby]

And there’s the problem: http://standards.ieee.org/faqs/regauth.html#10

EUIs cannot be resold or distributed.

For applications it should be ok as they are part of TTN but I wouldn’t necessarily say the same for devices.

The silicon based IDs are in effect a product of their own right and you are sharing the ID owned by someone else

[htdvisser (Hylke Visser)]

Looping in @romeovs here. He is behind the code that generates these random EUIs in the console.

[arjanvanb (Arjan)]

Looping in @romeovs here.

@romeovs, probably not worth the effort for V2, but maybe for V3:

I just had TTN Console generate 10 DevEUIs, and got one that is clashing with an existing EUI64 customer.

(I got 004C59D84BD91E68, 0097A5CCA573FA3E, 002D8C0A7C280EEE, 00675B8B1070F855, 00635D72B15B9004, the clashing 00004982AE205313, 00636772CEBB3CF2, 00BE347F2AF3C2D0, 00CE807951C97E62 and 008EC7AF48818B8B. All have MSB 0x00, hence all happen to be universally administered, but maybe other EUIs would have a different MSB. As an aside, editing a device to replace an existing DevEUI with a generated one, simply gets one the existing value again.)