I'd prefer to keep it completely independent from hashes. I'm already annoyed by native when it changes the hardware address everytime I restart and I forget the -i flag. I don't like it to be the case for every board to have a different address depending on the modules I compile in.

Ok, I agree. Here's another approach, that's mostly taken from OpenWSN. It seems a little bit arbitrary, but at least we will have the same EUI-64 addresses on the IoT-LAB.

Why not the XOR method you had earlier?

Why not the XOR method you had earlier?

I think it makes things easier if we have the same UIDs at least in OpenWSN and RIOT.

Then you maybe should adapt the xbee driver, too (if you want to make it dependent on the EUI-64)

Then you maybe should adapt the xbee driver, too (if you want to make it dependent on the EUI-64)

I cannot test this device and I don't understand the parts in brackets.

I don't understand the parts in brackets.

Currently the short address for this device is generated from CPU ID, too. However, if we take the scheme you proposed to take bytes of the EUI-64 for that, we should do that on the xbee device too (where the EUI-64 is preinitialized by the vendor).

Ah, okay. Yes, I'm much in favor of this.

Updated. Endianess not yet addressed, because a) I'm not sure what the right endianess and b) I think the driver should reflect this, too. Maybe another PR for that?

@cladmi, do you have some insights how to sensibly compute an EUI64 for the at86rf2xx?

And what is @haukepetersen's opinion on this?

@OlegHahm I would prefer a method that can be generally applied for ALL IEEE 802.15.4 devices (as long as they allow for that), not just the at86rf2xx ones.

I would prefer a method that can be generally applied for ALL IEEE 802.15.4 devices (as long as they allow for that), not just the at86rf2xx ones.

Apparently, that's not possible if weird devices as the XBEE not even allow to set the EUI-64.

That's why I wrote "(as long as they allow for that)".

Exceptions gonna except... let's at least have a general case for non-exceptions is all I'm saying.

Do you have a proposal?

As I proposed yesterday and you seem to ignore since then 😒: using "sliding XOR"

#if CPUID_ID_LEN
     uint8_t cpuid[CPU_ID_LEN];

     cpuid_get(cpuid);
#if CPUID_ID_LEN < 8
     /* in case CPUID_ID_LEN < 8, lead with zeros */
     for (int i = 0; i < (8 - CPUID_ID_LEN); i++) {
         addr_long[i] = 0;
     }

     for (int i = 0; i < CPUID_ID_LEN; i++) {
         addr_long[i + (8 - CPUID_ID_LEN)] = cpuid[i];
     }

 #else
    memset(addr_long, 0, 8);

    for (int i = 0; i < (CPUID_ID_LEN - 8); i++) {
         for (int j = i; j < 8; j++) {
             addr_long[j] ^= cpuid[i + j];
         } 
    }
#endif
#endif
    addr_long[0] &= ~0x01;    /* Ensure that address is unicast */
    addr_long[0] |= 0x02;     /* Ensure that address is local */

[edit: Set the EUI-64 unicast/group and local/universal bits accordingly]

I'm not ignoring it, but you haven't answered why you prefer this solution. I don't see how this is more generic. The CPUID is vendor specific anyway.

Oh… sorry somehow your question slipped through my radar. I prefer it, since it uses the entire CPUID compared to just parts of it.

Looks good to me, just one remark: If we take addr_long.uint16[0].u16 as short address for the atxx driver, the short addresses seem not to be unique, right? looking at these two generated addresses:

node1: 36:32:48:33:46:d5:9f:26
node2: 36:32:48:33:46:d8:9e:16

doesn't it make more sense to use addr_long.uint16[3].u16 as default short address for now?

Edit: never mind, byte ordering is not my strength...

Looks good to me know, ACK when squashed and Travis is happy.

Too bad, just found a duplicate long address with this scheme on IoT-LAB. :(

Without the last commit but puting

    /* make sure we mark the address as non-multicast and not globally unique */
    cpuid[0] &= ~(0x01);
    cpuid[0] |= 0x02;

in the right place the duplicate is gone...

Tested with 150 nodes on IoT-Lab. Don't have time to check for duplicates on all nodes.

What do you mean with right place? Isn't it in the right place in the current code?

Yes, but not in the version before the last commit.

Ah, I understand :-) Do you want to squash?

This code definitely result in duplicate EUI64 addresses on IoT-LAB. I have a somewhat weird patch that doesn't reveal duplicates on the 160 nodes I tested, but I'm not sure, what's the better approach.

Hm, are the CPUIDs on IoT-Lab nodes definitely unique?

You should probably ask ST, but I think, yes, they are. It's impossible to guarantee any uniqueness here if we don't know the exact nature of the CPUID. What I propose for the IoT-Lab case: we leave the calculation in this driver as it is with the current state of this PR and add something to the netif auto_init that set different addresses if required (indicated by, e.g., the board or the user).

sounds good. What I do not quite understand is the duplicate EUIs in the IoT-Lab, as XORed results from unique CPUIDs should acutally lead to unique EUIs. But anyhow, lets merge and improve afterwards.

ACK

Rebased without merge conflicts.

What I do not quite understand is the duplicate EUIs in the IoT-Lab, as XORed results from unique CPUIDs should acutally lead to unique EUIs.

We're basically mapping a (probably unique) 12 bit value to a an 8 bit value. Collisions may occur with every mapping scheme.

@OlegHahm: I can run my UID scripts to provide you all the CPUIDs of the working IoT-Lab nodes. I hope to give it by tomorrow evening, ping me on IRC if I don't.

https://gist.github.com/cladmi/06c5969be4f1e6e3254b

Almost every nodes. However half of grenoble,m3 nodes are missing because an experiment is currently run. The UID is printed in the uid8[0]->uid8[11] order and it also includes Paris that should be deployed "soon".

@OlegHahm @cladmi I checked the list that @cladmi posted using , there are no duplicates among the full CPUIDs
cat IoT-Lab\ CPUID | awk -F: '{ print $2; }' | sed -e 's/[", ]//g' -e '/^[ ]*$/d'| sort | uniq

When looking at these numbers, I get the feeling that i does make sense, to make the EUI creation platform dependent (-> then we can use known characteristics of the CPUIDs). So I am thinking, that it could make sense, to extend the cpuid module by a second function, maybe something like

void cpuid_get_unique_token(uint8_t res, sizte_t len);

In the implementation of that function we can than focus on known relevant bytes (e.g. bytes 3,9,10 for the iot-lab).

I think I like the idea. But should we merge this for now and make follow-up PR? Some duplicate EUI64s are less bad than identical EUI64s for all. 😉

Agreed. re-ACK and go.