Default setting for long/short hardware address

[PeterKietzmann]

Hi folks. I was thinking about hardware addresses and wanted to ask for your feedback in two concerns.

1. Currently the default long hardware address is set in the driver by getting the serial number of the CPU, XOR-ing the first and last 8 Bytes and converting the byte order (similar for Atmel and Freescale transceivers). However, looking at CPUIDs of several phyNodes it appears that (i) the first two bytes are "always" 0x00 and (ii) the last 8 Bytes don't really differ for that batch. The XOR operation results in numbers that are equal or similar in their first bytes but then the byte order gets swapped which results in hardware addresses with equal or similar endings.
2. The short hardware address is currently set by taking the last bytes of the long hardware address which may lead to collisions as described in 1. In RFC-4944 section 2 it is written:

"Short addresses being transient in nature, a word of caution is in order: since they are doled out by the PAN coordinator function during an association event, their validity and uniqueness is limited by the lifetime of that association."

That made me wonder if we're doing this in the best way. In addition @smlng already faced problems in a setup consisting of multiple phyNodes and a RasPi with Linux (would you give a short explanation please).

All in all my questions are:

• Is there a regulation that I'm not aware of about how to generate the long hardware address? From RFC-4291 section 2.5.1 I just read the the identifier needs to be unique for one subnet. In that case it would be legit to adapt the above described procedure, right? E.g. just not swapping the Byte order could already improve the situation for the phyNodes.
• Shouldn't be the generation of short addresses be more dynamic and probably somehow dependant on the PAN ID? Honestly I've no idea if this may interact with any kind of neighbour discovery. @authmillenon any insights?
• Is it required to set a short address on startup or would it be possible to wait for an "an association event" as indicated in RFC-4944 (see above)?

[OlegHahm]

see also #4233

[PeterKietzmann]

Would fix it though I like the fact that one node always the same address by default.

[OlegHahm]

I don't think that using RFC4193 would prevent this - and yes, I'm also much in favor of having the same ID for each node every time. Ideally the same on all supported OSes.

[miri64]

However, looking at CPUIDs of several phyNodes it appears that

Can you give me the pull request or branch for the port of these phyNodes? I can't find them.

(i) the first two bytes are "always" 0x00

Since that is just an obeservation and the CPUID is very much vendor specific I would refrain from assuming that this general thing from just one platform.

and (ii) the last 8 Bytes don't really differ for that batch. The XOR operation results in numbers that are equal or similar in their first bytes but then the byte order gets swapped which results in hardware addresses with equal or similar endings.

actually the swapping was (if I remember correctly) excactly because some other platform we previously tested for (iot-lab?) had it the other way around.

The short hardware address is currently set by taking the last bytes of the long hardware address

I used to be against this and wanted to have the full entropy provided by the CPUID in the short address too. Don't know what convinced me otherwise anymore.

1. Is there a regulation that I'm not aware of about how to generate the long hardware address? From RFC-4291 section 2.5.1 I just read the the identifier needs to be unique for one subnet. In that case it would be legit to adapt the above described procedure, right? E.g. just not swapping the Byte order could already improve the situation for the phyNodes.

As Oleg pointed out: RFC 4193 gives a decent way to generate an IID, if none is given. I don't know why swapping might be a problem here. The IID is 64-bit long so if the difference is at the beginning or shouldn't make much difference, except for adhering to the address structure an EUI-64 is supposed to have.

1. Shouldn't be the generation of short addresses be more dynamic and probably somehow dependant on the PAN ID? Honestly I've no idea if this may interact with any kind of neighbour discovery. @authmillenon any insights?

As I said, I would also add the rest of the CPUID to the short address and forget about relation to the EUI-64 for now. Regarding ND: this is more a problem of stateless auto-address configuration and duplicate address detection, then ND. While this is part of the specification for 6Lo-ND I would look at it rather seperate, because for identification 6Lo-ND MUST use the EUI-64 regardless (see https://tools.ietf.org/html/rfc6775#section-1.3). Duplicate address detection (which isn't fully implemented in RIOT btw, see #3052) only specifies, that an address mustn't be used by the interface if the address already exists in the subnet and (intentionally - since this is very interface-dependent) doesn't give any solution how to solve an address collision. For IEEE 802.15.4 short addresses it should suffice to either rely on a PAN coordinator or just incrementing both hardware address locally (if none is present) and reassigning a new IPv6 link-local and global unicast address so that it fits the new link-layer address, until a non-duplicate address is found via DAD.

[miri64]

Until DAD is implemented fully I would just set the link-layer addresses and the IPv6 addresses derived from it by hand (which is tedious, I know).

[miri64]

BTW: for the samr21-xpro there might be an "easier" way to fix at least the long addresses: according to the documentation MAC address assigned by Atmel for the radio is configured on the device, but it is only accessible through the EDBG interface :-/.

[PeterKietzmann]

Can you give me the pull request or branch for the port of these phyNodes? I can't find them.

Sorry, I was referring to the phytec board pba-d-01-kw2x with kinetis CPU kw2x and transceiver kw2xrf.

I would refrain from assuming that this general thing from just one platform.

That was my first impression too. But then I thought as long as the driver is vendor specific and the change is valid and improves "something" it should be fine. In addition I think it is probable that potential users buy a bunch of boards and may run into difficulties.

As Oleg pointed out: RFC 4193 gives a decent way to generate an IID, if none is given. I don't know why swapping might be a problem here

I admit that RFC 4193 gives a good way around that problem. The "problematic" byte swapping concerns the generation of short hardware addresses, maybe I didn't point it out properly. As described above, for CPUs I looked at, it turned out that one end of the generated identifier is likely to be not unique (zeros at the first two bytes of the CPUID and low entropy in bytes no 8-16 for products of one batch). This one should not be taken to set the short address.

Thanks for your opinions. If I got it correctly the "quick-fix" would be to adjust the short address generation to depend on the full CPUID. Are there any objections? @smlng would that solve your issues?

[miri64]

That was my first impression too. But then I thought as long as the driver is vendor specific and the change is valid and improves "something" it should be fine. In addition I think it is probable that potential users buy a bunch of boards and may run into difficulties.

The driver is vendor specific in the sense of the driver's vendor, yes. But the CPUID is coming from the MCU which might be a different vendor entirely ;-).

[PeterKietzmann]

For the hardware that we're talking about, MCU and radio are on one chip and I'm not aware that the radio is available separately. And as long as there is no rule on how to use CPUIDs for address generation, it should be meaningless if processing the "unique number" from left to right or right to left. Anyway, if there are no objections I will improve the situation by adapting the short address generation as proposed by you @authmillenon. Even if the short address generation might be adapted later, in terms of dynamic allocation...

[miri64]

👍

[smlng]

Hi all,

@PeterKietzmann, short answer: yes, this modified/fixed CPUID generation will (very likely) fix it ... However, as we already discussed offline, this is only one side of the medal.

---

Long(er) answer:

I'm not into details of CPUID generation, but I guess its a vendor specific think - hence EUI64 generation using CPUID cannot/shouldn't be generic for all boards?! From our observation, PhyTec seems to use non-random but some kind of incremental CPUID for their MCUs, which results in EUI64 that have very similar last bytes. These are link-local address of some PhyTecs nodes we have:

fe80::4be3:4e73:718d:600a
fe80::f8e3:4e62:71ba:600a
fe80::e0d3:4e71:71a8:600a
fe80::b993:4e72:7187:600a

Combined with the (other side of the medal:) static short address generation used now in RIOT, all these nodes will have the same short address assigned. Though, while changing/fixing CPUID for pba-d-01-kw2x will fix short address, I think short address generation should be fixed as well. The current approach of using a static generator function (last 2 bytes of EUI64) will likely pop up in other scenarios (real deployments) as well.

Btw. as @PeterKietzmann said, I discovered this issue while testing a setup with a RasPi (+openlabs) and 2 pba-d-01-kw2x with addresses from above. I found that one of the RIOT nodes discards all its unicast addresses during boot+address configuration when it discovers the other RIOT node with the same short address.

[jnohlgard]

@smlng The same problem exists on the Mulle as well (K60 CPU), they all end in 4012. I assume that the way Kinetis is assigning the CPUIDs causes the extremely simple hashing in setting the EUI64 to give constants for the last word like that.

[PeterKietzmann]

In summary, addresses derived from Kinetis CPUIDs tend to have constant last words. As it seems (to me) the kw2x transceiver will always come with a Kinetis CPU. At least I have never seen them separated from a CPU. But this situation might also appear with the Atmel transceiver used with a Kinets CPU, in our case on the Mulle board. However, we could improve the short address generation in all radio drivers as discussed above. This will lead to different short addresses (which is good) but long hardware addresses will still be equal or similar in their last bytes.

• Is that a problem somehow?

In addition the question arose what happens in RIOT in a setup consisting of multiple (radio) interfaces? If the addresses of both interfaces where generated in this way, shouldn't we consult an extra parameter for address generation, like interface number? I just never had this use case...

[jnohlgard]

I suggest we change the EUI generation to use some simple hashing algorithm, e.g. from sys/hashes/hashes.c, and also add the interface id (PID) as a part in the hash.

See also: http://www.azillionmonkeys.com/qed/hash.html

[miri64]

I suggest we change the EUI generation to use some simple hashing algorithm, e.g. from sys/hashes/hashes.c, and also add the interface id (PID) as a part in the hash.

There are two minor problems to that approach:

1. what if no interfaces are present (e.g. user just wants to use the bare-metal radio) or a different stack than GNRC is used.
   
   proposed solution: a common network interface API to get information from an interface (in the spirit of, but maybe a little more versatile than POSIX's net/if.h e.g.)
2. IIRC in lwIP it's not possible to initialize a device after the interface was initialized.
   
   proposed solution: find a way around it, shouldn't be too difficult, but would require some changes (either to my contrib code (:+1:) or upstream code (:-1:))

All in all, I would for now focus on getting a distinct value for every node (maybe as proposed in #4233?), apply my proposed solutions and then go for fixing #5055.

[smlng]

Adopting #4233 would (likely) result in a new/different IID on every boot, right? However, I like to have static IID and hence stable IPv6 address (global and link-local) on my sensors/RIOT nodes - at least for testing. So some kind of API to modify/set IID either on boot or via Makefile would be desirable, I guess?!

[miri64]

AFAIK, no it's just what @gebart suggested, just with a standardized hash.

[aeneby]

The more I read through the 802.15.4 spec, the more I'm convinced that the only valid "default" short address is 0xffff. This is alluded to throughout the spec - for example, Table 71 describes the short address as:

The 16 bit address that the device uses to communicate in the PAN. If the device is a PAN coordinator, this value shall be chosen before a PAN is started. Otherwise, the address is allocated by a coordinator during association. A value of 0xfffe indicates that the device has associated but has not been allocated an address. A value of 0xffff indicates that the device does not have a short address.

So the only way for a device to have a short address at all is to either be a PAN coordinator, or be issued one by a PAN coordinator. If neither of these things are true then the device simply doesn't have a short address, i.e. 0xffff.

[smlng]

@aeneby, I think you are right. But somehow the short address handling is (kind of) messed up in RIOT at the moment anyway. See my comment above regarding PhyNodes (pbd-d-01-kw2x) with same (wrong) short address, it seems that RIOT is considering short addresses during DAD (or some other mechanism behind the scenes) and discards its IP addresses. So even if 0xffff is used in RIOT as default short address if coordinator absence, something else might come in our way.

So in short: there is more todo than simply fix short address assignment. This might be related to header compression, where short addresses come into play?!

On the otherhand, I thing @alexaring et al from @linux-wpan are working on (or already have) implementing some PAN coordinator stuff on the Linux side?

[alexaring]

No, we don't have any pan coordinator functionality yet. But I have some idea's what's currently missing and "basic" how to implement it We don't support any MLME-OPS, I think we should start to implement one MLME-ops, the other MLME-ops will come... then we have some basic stuff e.g. synced xmit function with return value of transmission state (e.g. ACK was there or not).

The whole coordinator stuff is also much difficult, some parts need to be run in userspace and trigger/event listenting in kernel nl802154 MLME-ops. It's just the same thing like "hostapd" in wireless to run as AP.

Because the short address handling, we do 0xffff as default... but Linux has some way to run some setup scripts etc. so I can understand RIOT-OS decision to not use MIB default.

[JohannaOm]

Hello!
Does the protocol currently work as a nonbeacon-enabled PAN?
Does it include duty-cycling?

[PeterKietzmann]

My initial concern has been fixed but if I see it correctly, this issue raised the question about the need for short addresses in non-PAN-coordinated networks in general. Is that correct?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.