Generated Device EUI clashes with officially assigned EUIs

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

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?

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.

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
Range: 00:17:02:00:00:00 - 00:17:02:FF:FF:FF

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

1 Like

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:

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

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

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… :slight_smile:

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?)

And there’s the problem:

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

1 Like

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

@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.)

1 Like