cpuid: multiple radios will get same EUI-64

[OlegHahm]

Since the CPUID is taken to generate the EUI-64 for radios that don't store such an address somewhere on the chip, having multiple radios of this kind, would end up in having multiple radios with the same address. A simple solution could be to add the interface number to the EUI-64.

[miri64]

Your solution would be very specific to GNRC, but I could imagine some kind of running number for hardware addresses. However, this needs to be done somewhat efficiently.

[OlegHahm]

I don't see how my exemplary solution should be specific to GNRC.

[miri64]

Because the fact that the interfaces have a number is very specific to GNRC (or any other stack that uses numbers to identify interfaces in general). lwIP uses a pointer to the struct netif struct to identify its interfaces and for emb6/UIP the concept of interfaces isn't even implemented. The network device itself is just identified by its device descriptor, which is a pointer to a netdev2_t struct, which could be basically allocated anywhere (in our usual setup it's in the C file of their auto initialization, but that does not need to be a given).

Sure, we can use any of these values for the hardware address (I bet this issue won't only be the case for 64-bit addresses, but also other lengths ;)), but I would prefer a solution that provides the same value for any setup.

[kaspar030]

I would prefer a solution that provides the same value for any setup.

Everyone would, but do you have such a solution in mind? If not, let's go for something that is simple, works, and can be changed.

[OlegHahm]

Because the fact that the interfaces have a number is very specific to GNRC

Numbering interfaces is something you can completely independent from the stack. I'm not even 100% sure which number from GNRC you're referring to.

[miri64]

I proposed a solution in #5055 (comment): It's to ways we can have this. The simple solution would be: have a running 8-bit number that just counts up and is included into the hardware addresses (though we need to look into how to incorporate such a number in an 8-bit radio address as for the cc11xx radio e.g.). The more complex solution, that would also make the value constant throughout setups: have a running number for each model of device and an identifying number for each model (similarly how USB devices are identified). Then combine those two with the CPU-ID for the hardware address.

[miri64]

Because the fact that the interfaces have a number is very specific to GNRC

Numbering interfaces is something you can completely independent from the stack. I'm not even 100% sure which number from GNRC you're referring to.

For the specific GNRC case I was referring to the PID of the interface (to my knowledge there is no other interface number yet), but even a running number for the interface is very stack specific, since it depends on how the stack initializes its interfaces.

[miri64]

Everyone would, but do you have such a solution in mind? If not, let's
go for something that is simple, works, and can be changed.

This is not a pressing matter IMHO, it is a bug yes, but a bug that can temporarily be fixed very easy by just setting another hardware address if you happen to have two devices of the same type on a node. Instead of trying to get a quick solution let's discuss our options here and find a way that both isn't too complicated and satisfies our requirements (and lets keep also in mind that it is usually the vendors job to set a unique ID for their device ;-)).