[PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Lennert Buytenhek]

Currently, ieee802154_random_extended_addr() has a 50% chance of
generating a group (multicast) address, while this function is used
for generating station addresses (which can't be group addresses)
for interfaces that don't have a hardware-provided address.

Also, in case get_random_bytes() generates the EUI-64 address
00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
address, ieee802154_random_extended_addr() reacts by changing it
to 01:00:00:00:00:00:00:00, which is an invalid station address as
well, as it is a group address.

This patch changes the address generation procedure to grab eight
random bytes, treat that as an EUI-64, and then clear the Group
address bit and set the Locally Administered bit, which is in
line with how eth_random_addr() generates random EUI-48s.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
---
 include/linux/ieee802154.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/ieee802154.h b/include/linux/ieee802154.h
index 8872ca1..552210d 100644
--- a/include/linux/ieee802154.h
+++ b/include/linux/ieee802154.h
@@ -244,9 +244,9 @@ static inline void ieee802154_random_extended_addr(__le64 *addr)
 {
 	get_random_bytes(addr, IEEE802154_EXTENDED_ADDR_LEN);
 
-	/* toggle some bit if we hit an invalid extended addr */
-	if (!ieee802154_is_valid_extended_addr(*addr))
-		((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN - 1] ^= 0x01;
+	/* clear the group bit, and set the locally administered bit */
+	((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN - 1] &= ~0x01;
+	((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN - 1] |= 0x02;
 }
 
 #endif /* LINUX_IEEE802154_H */
-- 
2.4.1

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Alexander Aring]

On Thu, May 28, 2015 at 03:38:32PM +0300, Lennert Buytenhek wrote:
> Currently, ieee802154_random_extended_addr() has a 50% chance of
> generating a group (multicast) address, while this function is used
> for generating station addresses (which can't be group addresses)
> for interfaces that don't have a hardware-provided address.
> 
> Also, in case get_random_bytes() generates the EUI-64 address
> 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> address, ieee802154_random_extended_addr() reacts by changing it
> to 01:00:00:00:00:00:00:00, which is an invalid station address as
> well, as it is a group address.
> 
> This patch changes the address generation procedure to grab eight
> random bytes, treat that as an EUI-64, and then clear the Group
> address bit and set the Locally Administered bit, which is in
> line with how eth_random_addr() generates random EUI-48s.
> 

This is one thing which I asked myself already. If the group address
comming from EUI-64 standard or not. What I can say is that the 802.15.4
MAC layer doesn't care about this bit and we don't have _any_ multicast
functionality.

What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The
802.15.4 have no special bits inside the EUI64 which indicates
something. Our multicast functionality is done by a broadcast (done by
short address, which is currently indicate by a 0xff..ff extended addr,
because IPv6 can't deal at the moment deal with two types of mac address
types.)

What I always find is this document [0]. Which describes that the
0x00..00 and 0xff...ff are invalid. (And a node should really not use
0xff..ff since we have the workaround with IPv6 for broadcast).


If we would have such bit, then we also need to implement [1], which
generates the multicast address according the IPv6 address. At the
moment we get the dev->broadcast address which is correct, because we
don't have multicast functionality.


I don't ack this patch, because I don't see at the moment that this is
wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a
multicast on L2 _then_ we should change it, but I don't think that IPv6
do that.

- Alex

[0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
[1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Lennert Buytenhek]

On Thu, May 28, 2015 at 03:17:15PM +0200, Alexander Aring wrote:

> > Currently, ieee802154_random_extended_addr() has a 50% chance of
> > generating a group (multicast) address, while this function is used
> > for generating station addresses (which can't be group addresses)
> > for interfaces that don't have a hardware-provided address.
> > 
> > Also, in case get_random_bytes() generates the EUI-64 address
> > 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> > address, ieee802154_random_extended_addr() reacts by changing it
> > to 01:00:00:00:00:00:00:00, which is an invalid station address as
> > well, as it is a group address.
> > 
> > This patch changes the address generation procedure to grab eight
> > random bytes, treat that as an EUI-64, and then clear the Group
> > address bit and set the Locally Administered bit, which is in
> > line with how eth_random_addr() generates random EUI-48s.
> 
> This is one thing which I asked myself already. If the group address
> comming from EUI-64 standard or not. What I can say is that the 802.15.4
> MAC layer doesn't care about this bit and we don't have _any_ multicast
> functionality.
> 
> What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The
> 802.15.4 have no special bits inside the EUI64 which indicates
> something. Our multicast functionality is done by a broadcast (done by
> short address, which is currently indicate by a 0xff..ff extended addr,
> because IPv6 can't deal at the moment deal with two types of mac address
> types.)
> 
> What I always find is this document [0]. Which describes that the
> 0x00..00 and 0xff...ff are invalid. (And a node should really not use
> 0xff..ff since we have the workaround with IPv6 for broadcast).
> 
> 
> If we would have such bit, then we also need to implement [1], which
> generates the multicast address according the IPv6 address. At the
> moment we get the dev->broadcast address which is correct, because we
> don't have multicast functionality.
> 
> 
> I don't ack this patch, because I don't see at the moment that this is
> wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a
> multicast on L2 _then_ we should change it, but I don't think that IPv6
> do that.
> 
> - Alex
> 
> [0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
> [1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264

Your [0] document states that EUI-64 addresses start with an OUI,
and the structure of the OUI is documented in this document:

	https://standards.ieee.org/develop/regauth/tut/eui.pdf

Page 4 of this document shows that every OUI(/CID) contains the
Universal/Local and Individual/Group address bits, and this is
true no matter whether this OUI is part of an EUI-48 or an EUI-64.

Also compare your [0] with this document:

	http://standards.ieee.org/develop/regauth/tut/eui48.pdf

And note how neither the EUI-48 nor the EUI-64 PDFs talk about group
addresses -- this is because an EUI-{48,64} contains an OUI, and the
OUI contains the scope/group bits, and so the documents explaining
the EUI-{48,64} format are not the right place to discuss those bits,
although they exist both in EUI-48 and in EUI-64 addresses.

Just the fact that 802.15.4 spec doesn't talk about multicast doesn't
suddenly redefine the EUI-64 group bit as just another unicast address
bit, in my humble opinion, but this is what Linux is currently doing.

 From a hardware point of view, multicast packets should never be
ACKed, so there is no need for the hardware to be aware of the active
multicast addresses on this interface per se.  (We could theoretically
pass the multicast address list for the interface to the hardware to
allow doing frame filtering in hardware, but this does not affect
operational correctness.)

Whether we should be using EUI-64 group addresses on the "wire" for
802.15.4 for multicast (IPv6) traffic is another question, but using
EUI-64 group addresses as station addresses just because the link
layer doesn't define multicast functionality is wrong from my point
of view.

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Lennert Buytenhek]

On Thu, May 28, 2015 at 04:39:48PM +0300, Lennert Buytenhek wrote:

> > > Currently, ieee802154_random_extended_addr() has a 50% chance of
> > > generating a group (multicast) address, while this function is used
> > > for generating station addresses (which can't be group addresses)
> > > for interfaces that don't have a hardware-provided address.
> > > 
> > > Also, in case get_random_bytes() generates the EUI-64 address
> > > 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> > > address, ieee802154_random_extended_addr() reacts by changing it
> > > to 01:00:00:00:00:00:00:00, which is an invalid station address as
> > > well, as it is a group address.
> > > 
> > > This patch changes the address generation procedure to grab eight
> > > random bytes, treat that as an EUI-64, and then clear the Group
> > > address bit and set the Locally Administered bit, which is in
> > > line with how eth_random_addr() generates random EUI-48s.
> > 
> > This is one thing which I asked myself already. If the group address
> > comming from EUI-64 standard or not. What I can say is that the 802.15.4
> > MAC layer doesn't care about this bit and we don't have _any_ multicast
> > functionality.
> > 
> > What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The
> > 802.15.4 have no special bits inside the EUI64 which indicates
> > something. Our multicast functionality is done by a broadcast (done by
> > short address, which is currently indicate by a 0xff..ff extended addr,
> > because IPv6 can't deal at the moment deal with two types of mac address
> > types.)
> > 
> > What I always find is this document [0]. Which describes that the
> > 0x00..00 and 0xff...ff are invalid. (And a node should really not use
> > 0xff..ff since we have the workaround with IPv6 for broadcast).
> > 
> > 
> > If we would have such bit, then we also need to implement [1], which
> > generates the multicast address according the IPv6 address. At the
> > moment we get the dev->broadcast address which is correct, because we
> > don't have multicast functionality.
> > 
> > 
> > I don't ack this patch, because I don't see at the moment that this is
> > wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a
> > multicast on L2 _then_ we should change it, but I don't think that IPv6
> > do that.
> > 
> > - Alex
> > 
> > [0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
> > [1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264
> 
> Your [0] document states that EUI-64 addresses start with an OUI,
> and the structure of the OUI is documented in this document:
> 
> 	https://standards.ieee.org/develop/regauth/tut/eui.pdf
> 
> Page 4 of this document shows that every OUI(/CID) contains the
> Universal/Local and Individual/Group address bits, and this is
> true no matter whether this OUI is part of an EUI-48 or an EUI-64.
> 
> Also compare your [0] with this document:
> 
> 	http://standards.ieee.org/develop/regauth/tut/eui48.pdf
> 
> And note how neither the EUI-48 nor the EUI-64 PDFs talk about group
> addresses -- this is because an EUI-{48,64} contains an OUI, and the
> OUI contains the scope/group bits, and so the documents explaining
> the EUI-{48,64} format are not the right place to discuss those bits,
> although they exist both in EUI-48 and in EUI-64 addresses.
> 
> Just the fact that 802.15.4 spec doesn't talk about multicast doesn't
> suddenly redefine the EUI-64 group bit as just another unicast address
> bit, in my humble opinion, but this is what Linux is currently doing.
> 
> >From a hardware point of view, multicast packets should never be
> ACKed, so there is no need for the hardware to be aware of the active
> multicast addresses on this interface per se.  (We could theoretically
> pass the multicast address list for the interface to the hardware to
> allow doing frame filtering in hardware, but this does not affect
> operational correctness.)
> 
> Whether we should be using EUI-64 group addresses on the "wire" for
> 802.15.4 for multicast (IPv6) traffic is another question, but using
> EUI-64 group addresses as station addresses just because the link
> layer doesn't define multicast functionality is wrong from my point
> of view.

Appendix A in RFC4291 also seems to confirm that the scope/group bits
are an inherent part of any EUI-64 address:

	http://tools.ietf.org/html/rfc4291#page-20

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Alexander Aring]

On Thu, May 28, 2015 at 04:39:48PM +0300, Lennert Buytenhek wrote:
> On Thu, May 28, 2015 at 03:17:15PM +0200, Alexander Aring wrote:
> 
> > > Currently, ieee802154_random_extended_addr() has a 50% chance of
> > > generating a group (multicast) address, while this function is used
> > > for generating station addresses (which can't be group addresses)
> > > for interfaces that don't have a hardware-provided address.
> > > 
> > > Also, in case get_random_bytes() generates the EUI-64 address
> > > 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> > > address, ieee802154_random_extended_addr() reacts by changing it
> > > to 01:00:00:00:00:00:00:00, which is an invalid station address as
> > > well, as it is a group address.
> > > 
> > > This patch changes the address generation procedure to grab eight
> > > random bytes, treat that as an EUI-64, and then clear the Group
> > > address bit and set the Locally Administered bit, which is in
> > > line with how eth_random_addr() generates random EUI-48s.
> > 
> > This is one thing which I asked myself already. If the group address
> > comming from EUI-64 standard or not. What I can say is that the 802.15.4
> > MAC layer doesn't care about this bit and we don't have _any_ multicast
> > functionality.
> > 
> > What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The
> > 802.15.4 have no special bits inside the EUI64 which indicates
> > something. Our multicast functionality is done by a broadcast (done by
> > short address, which is currently indicate by a 0xff..ff extended addr,
> > because IPv6 can't deal at the moment deal with two types of mac address
> > types.)
> > 
> > What I always find is this document [0]. Which describes that the
> > 0x00..00 and 0xff...ff are invalid. (And a node should really not use
> > 0xff..ff since we have the workaround with IPv6 for broadcast).
> > 
> > 
> > If we would have such bit, then we also need to implement [1], which
> > generates the multicast address according the IPv6 address. At the
> > moment we get the dev->broadcast address which is correct, because we
> > don't have multicast functionality.
> > 
> > 
> > I don't ack this patch, because I don't see at the moment that this is
> > wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a
> > multicast on L2 _then_ we should change it, but I don't think that IPv6
> > do that.
> > 
> > - Alex
> > 
> > [0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
> > [1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264
> 
> Your [0] document states that EUI-64 addresses start with an OUI,
> and the structure of the OUI is documented in this document:
> 
> 	https://standards.ieee.org/develop/regauth/tut/eui.pdf
> 
> Page 4 of this document shows that every OUI(/CID) contains the
> Universal/Local and Individual/Group address bits, and this is
> true no matter whether this OUI is part of an EUI-48 or an EUI-64.
> 

yes this makes sense and one argument to change it to your behaviour.

> Also compare your [0] with this document:
> 
> 	http://standards.ieee.org/develop/regauth/tut/eui48.pdf
> 
> And note how neither the EUI-48 nor the EUI-64 PDFs talk about group
> addresses -- this is because an EUI-{48,64} contains an OUI, and the
> OUI contains the scope/group bits, and so the documents explaining
> the EUI-{48,64} format are not the right place to discuss those bits,
> although they exist both in EUI-48 and in EUI-64 addresses.
> 
> Just the fact that 802.15.4 spec doesn't talk about multicast doesn't
> suddenly redefine the EUI-64 group bit as just another unicast address
> bit, in my humble opinion, but this is what Linux is currently doing.
>

The 802.15.4 spec doesn't also say any words about that the "extended
address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a
EUI-64 [1]. General question is "Is the extended-address in 802.15.4
really meaning an EUI-64 address?". Sorry for this newbie question, but
this is what I am asking myself now.

What I see is that the extended-addr is described as "The 64-bit (IEEE)
address assigned to the device." Which says to me it's an EUI-64, or?

But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't
deal with the 0x00..00.

> From a hardware point of view, multicast packets should never be
> ACKed, so there is no need for the hardware to be aware of the active
> multicast addresses on this interface per se.  (We could theoretically
> pass the multicast address list for the interface to the hardware to
> allow doing frame filtering in hardware, but this does not affect
> operational correctness.)

So then we should also add a check of this bit at [0]? Then set the
ackreq bit to 0 if the bit is set?

> 
> Whether we should be using EUI-64 group addresses on the "wire" for
> 802.15.4 for multicast (IPv6) traffic is another question, but using
> EUI-64 group addresses as station addresses just because the link
> layer doesn't define multicast functionality is wrong from my point
> of view.

When this address is invalid and the MAC layer doesn't use this bit.
Then we need to care that we drop all frames with the source address
with this bit. I also don't see that any transceiver with address
filtering enabled will drop this frame (okay they also don't filter 0x00..00
and 0xff...ff) frames.

I am currently really unsure and looking in well-known IoT OS, if they
look on this bit. But I didn't saw anything. Only that the most using
the same like eth_random_addr address and fill with ff fe bit pattern.
Maybe to operate with some virtual linux networking ethernet interfaces
which are connected over slip and tun/tap and such things...

- Alex

[0] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/tx.c#L219
[1] https://tools.ietf.org/html/rfc4944#section-6

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Alexander Aring]

Grml, I think I am getting too much confuses right now.

On Thu, May 28, 2015 at 04:42:49PM +0200, Alexander Aring wrote:
> On Thu, May 28, 2015 at 04:39:48PM +0300, Lennert Buytenhek wrote:
> > On Thu, May 28, 2015 at 03:17:15PM +0200, Alexander Aring wrote:
> > 
> > > > Currently, ieee802154_random_extended_addr() has a 50% chance of
> > > > generating a group (multicast) address, while this function is used
> > > > for generating station addresses (which can't be group addresses)
> > > > for interfaces that don't have a hardware-provided address.
> > > > 
> > > > Also, in case get_random_bytes() generates the EUI-64 address
> > > > 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> > > > address, ieee802154_random_extended_addr() reacts by changing it
> > > > to 01:00:00:00:00:00:00:00, which is an invalid station address as
> > > > well, as it is a group address.
> > > > 
> > > > This patch changes the address generation procedure to grab eight
> > > > random bytes, treat that as an EUI-64, and then clear the Group
> > > > address bit and set the Locally Administered bit, which is in
> > > > line with how eth_random_addr() generates random EUI-48s.
> > > 
> > > This is one thing which I asked myself already. If the group address
> > > comming from EUI-64 standard or not. What I can say is that the 802.15.4
> > > MAC layer doesn't care about this bit and we don't have _any_ multicast
> > > functionality.
> > > 
> > > What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The
> > > 802.15.4 have no special bits inside the EUI64 which indicates
> > > something. Our multicast functionality is done by a broadcast (done by
> > > short address, which is currently indicate by a 0xff..ff extended addr,
> > > because IPv6 can't deal at the moment deal with two types of mac address
> > > types.)
> > > 
> > > What I always find is this document [0]. Which describes that the
> > > 0x00..00 and 0xff...ff are invalid. (And a node should really not use
> > > 0xff..ff since we have the workaround with IPv6 for broadcast).
> > > 
> > > 
> > > If we would have such bit, then we also need to implement [1], which
> > > generates the multicast address according the IPv6 address. At the
> > > moment we get the dev->broadcast address which is correct, because we
> > > don't have multicast functionality.
> > > 
> > > 
> > > I don't ack this patch, because I don't see at the moment that this is
> > > wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a
> > > multicast on L2 _then_ we should change it, but I don't think that IPv6
> > > do that.
> > > 
> > > - Alex
> > > 
> > > [0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
> > > [1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264
> > 
> > Your [0] document states that EUI-64 addresses start with an OUI,
> > and the structure of the OUI is documented in this document:
> > 
> > 	https://standards.ieee.org/develop/regauth/tut/eui.pdf
> > 
> > Page 4 of this document shows that every OUI(/CID) contains the
> > Universal/Local and Individual/Group address bits, and this is
> > true no matter whether this OUI is part of an EUI-48 or an EUI-64.
> > 
> 
> yes this makes sense and one argument to change it to your behaviour.
> 
> > Also compare your [0] with this document:
> > 
> > 	http://standards.ieee.org/develop/regauth/tut/eui48.pdf
> > 
> > And note how neither the EUI-48 nor the EUI-64 PDFs talk about group
> > addresses -- this is because an EUI-{48,64} contains an OUI, and the
> > OUI contains the scope/group bits, and so the documents explaining
> > the EUI-{48,64} format are not the right place to discuss those bits,
> > although they exist both in EUI-48 and in EUI-64 addresses.
> > 
> > Just the fact that 802.15.4 spec doesn't talk about multicast doesn't
> > suddenly redefine the EUI-64 group bit as just another unicast address
> > bit, in my humble opinion, but this is what Linux is currently doing.
> >
> 
> The 802.15.4 spec doesn't also say any words about that the "extended
> address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a
> EUI-64 [1]. General question is "Is the extended-address in 802.15.4
> really meaning an EUI-64 address?". Sorry for this newbie question, but
> this is what I am asking myself now.
> 
> What I see is that the extended-addr is described as "The 64-bit (IEEE)
> address assigned to the device." Which says to me it's an EUI-64, or?
> 
> But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't
> deal with the 0x00..00.
> 

forget this sentence. I mean this is true when extended_addr != EUI-64
but I don't think that's true.

> > From a hardware point of view, multicast packets should never be
> > ACKed, so there is no need for the hardware to be aware of the active
> > multicast addresses on this interface per se.  (We could theoretically
> > pass the multicast address list for the interface to the hardware to
> > allow doing frame filtering in hardware, but this does not affect
> > operational correctness.)
> 
> So then we should also add a check of this bit at [0]? Then set the
> ackreq bit to 0 if the bit is set?
> 
> > 
> > Whether we should be using EUI-64 group addresses on the "wire" for
> > 802.15.4 for multicast (IPv6) traffic is another question, but using
> > EUI-64 group addresses as station addresses just because the link
> > layer doesn't define multicast functionality is wrong from my point
> > of view.
> 
> When this address is invalid and the MAC layer doesn't use this bit.
> Then we need to care that we drop all frames with the source address
> with this bit. I also don't see that any transceiver with address
> filtering enabled will drop this frame (okay they also don't filter 0x00..00
> and 0xff...ff) frames.
> 

I mean here how we should react globally about source address which have
this bit set? When it's source address then we should drop it and
destination address? I don't know. :-)

- Alex

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Phoebe Buckheister]

On Thu, 28 May 2015 15:38:32 +0300
Lennert Buytenhek <buytenh@wantstofly.org> wrote:

> Currently, ieee802154_random_extended_addr() has a 50% chance of
> generating a group (multicast) address, while this function is used
> for generating station addresses (which can't be group addresses)
> for interfaces that don't have a hardware-provided address.
> 
> Also, in case get_random_bytes() generates the EUI-64 address
> 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> address, ieee802154_random_extended_addr() reacts by changing it
> to 01:00:00:00:00:00:00:00, which is an invalid station address as
> well, as it is a group address.
> 
> This patch changes the address generation procedure to grab eight
> random bytes, treat that as an EUI-64, and then clear the Group
> address bit and set the Locally Administered bit, which is in
> line with how eth_random_addr() generates random EUI-48s.

Looks good to me. Even if this ends up being uneccessarily strict, we'll
always have a huge pool of addresses we may generate.
Note: the standard only says that the address shall be a 64 bit
universal address (not excluding multicast), but not generating
multicast EUIs seems like a good idea anyway.
 
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
> ---
>  include/linux/ieee802154.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/ieee802154.h b/include/linux/ieee802154.h
> index 8872ca1..552210d 100644
> --- a/include/linux/ieee802154.h
> +++ b/include/linux/ieee802154.h
> @@ -244,9 +244,9 @@ static inline void
> ieee802154_random_extended_addr(__le64 *addr) {
>  	get_random_bytes(addr, IEEE802154_EXTENDED_ADDR_LEN);
>  
> -	/* toggle some bit if we hit an invalid extended addr */
> -	if (!ieee802154_is_valid_extended_addr(*addr))
> -		((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN - 1] ^=
> 0x01;
> +	/* clear the group bit, and set the locally administered bit
> */
> +	((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN - 1] &= ~0x01;
> +	((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN - 1] |= 0x02;
>  }
>  
>  #endif /* LINUX_IEEE802154_H */

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Alexander Aring]

Hi,

On Thu, May 28, 2015 at 05:13:15PM +0200, Phoebe Buckheister wrote:
> On Thu, 28 May 2015 15:38:32 +0300
> Lennert Buytenhek <buytenh@wantstofly.org> wrote:
> 
> > Currently, ieee802154_random_extended_addr() has a 50% chance of
> > generating a group (multicast) address, while this function is used
> > for generating station addresses (which can't be group addresses)
> > for interfaces that don't have a hardware-provided address.
> > 
> > Also, in case get_random_bytes() generates the EUI-64 address
> > 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> > address, ieee802154_random_extended_addr() reacts by changing it
> > to 01:00:00:00:00:00:00:00, which is an invalid station address as
> > well, as it is a group address.
> > 
> > This patch changes the address generation procedure to grab eight
> > random bytes, treat that as an EUI-64, and then clear the Group
> > address bit and set the Locally Administered bit, which is in
> > line with how eth_random_addr() generates random EUI-48s.
> 
> Looks good to me. Even if this ends up being uneccessarily strict, we'll
> always have a huge pool of addresses we may generate.
> Note: the standard only says that the address shall be a 64 bit
> universal address (not excluding multicast), but not generating
> multicast EUIs seems like a good idea anyway.
>  

thanks Phoebe for clarify this. You both convince me to change it.

Thanks that we clarify this.

> > Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>

Acked-by: Alexander Aring <alex.aring@gmail.com>

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Marcel Holtmann]

Hi Lennert,

> Currently, ieee802154_random_extended_addr() has a 50% chance of
> generating a group (multicast) address, while this function is used
> for generating station addresses (which can't be group addresses)
> for interfaces that don't have a hardware-provided address.
> 
> Also, in case get_random_bytes() generates the EUI-64 address
> 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid
> address, ieee802154_random_extended_addr() reacts by changing it
> to 01:00:00:00:00:00:00:00, which is an invalid station address as
> well, as it is a group address.
> 
> This patch changes the address generation procedure to grab eight
> random bytes, treat that as an EUI-64, and then clear the Group
> address bit and set the Locally Administered bit, which is in
> line with how eth_random_addr() generates random EUI-48s.
> 
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
> ---
> include/linux/ieee802154.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Lennert Buytenhek]

On Thu, May 28, 2015 at 04:42:53PM +0200, Alexander Aring wrote:

> > Also compare your [0] with this document:
> > 
> > 	http://standards.ieee.org/develop/regauth/tut/eui48.pdf
> > 
> > And note how neither the EUI-48 nor the EUI-64 PDFs talk about group
> > addresses -- this is because an EUI-{48,64} contains an OUI, and the
> > OUI contains the scope/group bits, and so the documents explaining
> > the EUI-{48,64} format are not the right place to discuss those bits,
> > although they exist both in EUI-48 and in EUI-64 addresses.
> > 
> > Just the fact that 802.15.4 spec doesn't talk about multicast doesn't
> > suddenly redefine the EUI-64 group bit as just another unicast address
> > bit, in my humble opinion, but this is what Linux is currently doing.
> 
> The 802.15.4 spec doesn't also say any words about that the "extended
> address" is an EUI-64 address.  6LoWPAN RFC says it should handled like a
> EUI-64 [1]. General question is "Is the extended-address in 802.15.4
> really meaning an EUI-64 address?". Sorry for this newbie question, but
> this is what I am asking myself now.
> 
> What I see is that the extended-addr is described as "The 64-bit (IEEE)
> address assigned to the device." Which says to me it's an EUI-64, or?

You are right that there are no occurences of the "OUI" or "EUI"
strings in the 802.15.4 spec (good observation -- I hadn't noticed
this before!).  I'm basing my assumption that 802.15.4 64 bit
addresses are EUI-64s on this remark in 802.15.4-2011 section 5.2:

	A device’s extended address shall be a 64-bit universal
	address, as defined by the IEEE Registration Authority. [5]

Where footnote 5 is:

	[5] Interested applicants should contact the IEEE Registration
	Authority, http://standards.ieee.org/develop/regauth/.

On this web page, the only listed IEEE registries that seem relevant
ot me are the OUI registries (MA-L, MA-M, MA-S) -- none of the other
registries look like they could be the ones referenced by this remark
in the 802.15.4 spec.  This to me suggests that the 64 bit address
is an EUI-64, even if the literal term "EUI-64" isn't used anywhere.

And, as you remarked as well, there are several other references
online that suggest that 802.15.4 addresses are EUI-64s, for example
this TI FAQ page:

	https://e2e.ti.com/support/wireless_connectivity/w/design_notes/acquiring-ieee-address-range-802-15-4-mac-z-stack-zigbee-cc2420-cc2430-cc2431-cc2530-cc2531

Which has:

	Q: FAQ: Acquiring IEEE address range (802.15.4 MAC, Z-stack,
	ZigBee, CC2420, CC2430, CC2431, CC2530, CC2531)

	The IEEE 64 bit address is known at IEEE as the EUI-64(tm)
	which is a concatenation of the 24-bit OUI (Company ID) value
	assigned by the IEEE Registration Authority and a 40-bit
	extension identifier assigned by the organization with that
	OUI assignment.

	A one time fee of $1,650.00(US) is required. The addresses
	used for 802.15.4 has the same format and ranges as Ethernet
	MAC addresses.


> But then this means 0x00..00 and 0xff..ff are also valid, but IPv6
> can't deal with the 0x00..00.

0xff..ff wouldn't be valid as a station address as it is a group
address, and https://standards.ieee.org/develop/regauth/tut/eui64.pdf
also contains this remark:

	The all-zeros and all-ones EUI-64 values,
	00-00-00-00-00-00-00-00_hex and FF-FF-FF-FF-FF-FF-FF-FF_hex,
	are owned by the IEEE Registration Authority and will never
	be assigned, and are invalid for use as identifiers.


> > From a hardware point of view, multicast packets should never be
> > ACKed, so there is no need for the hardware to be aware of the active
> > multicast addresses on this interface per se.  (We could theoretically
> > pass the multicast address list for the interface to the hardware to
> > allow doing frame filtering in hardware, but this does not affect
> > operational correctness.)
> 
> So then we should also add a check of this bit at [0]? Then set the
> ackreq bit to 0 if the bit is set?

I would think so, but also, all v6 multicast addresses should be
mapped to the broadcast short address (when not using mesh mode),
according to RFC4944:

	This document assumes that a PAN maps to a specific IPv6 link.  This
	complies with the recommendation that shared networks support link-
	layer subnet [RFC3819] broadcast.  Strictly speaking, it is multicast
	not broadcast that exists in IPv6.  However, multicast is not
	supported natively in IEEE 802.15.4.  Hence, IPv6 level multicast
	packets MUST be carried as link-layer broadcast frames in IEEE
	802.15.4 networks.  This MUST be done such that the broadcast frames
	are only heeded by devices within the specific PAN of the link in
	question.  As per Section 7.5.6.2 in [ieee802.15.4], this is
	accomplished as follows:

	1.  A destination PAN identifier is included in the frame, and it
	    MUST match the PAN ID of the link in question.

	2.  A short destination address is included in the frame, and it MUST
	    match the broadcast address (0xffff).

So I thiiiink (but I haven't had my morning caffeine yet) that the
lowpan_is_addr_broadcast() check in lowpan_header() should be matching
on all multicast destination addresses instead.


> > Whether we should be using EUI-64 group addresses on the "wire" for
> > 802.15.4 for multicast (IPv6) traffic is another question, but using
> > EUI-64 group addresses as station addresses just because the link
> > layer doesn't define multicast functionality is wrong from my point
> > of view.
> 
> When this address is invalid and the MAC layer doesn't use this bit.
> Then we need to care that we drop all frames with the source address
> with this bit. I also don't see that any transceiver with address
> filtering enabled will drop this frame (okay they also don't filter
> 0x00..00 and 0xff...ff) frames.

For 802.3 ("plain" ethernet), we drop frames that have the group
address bit set in the frame source address, and in theory we should
probably be doing the same for 802.15.4, but in practise, I don't
think we can justify making this change now, as we already have an
installed base that happily uses group addresses as station addresses,
and making this change would break compatibility with those devices,
with no obvious advantage other than spec compliance.

If some future 802.15.4 stack change makes it necessary to start
dropping received frames with the group address bit set in the
source address, then I guess we can consider it, but at this point
I just don't see enough justification to intentionally break
communication with older Linux boxes with 50% probability (which
is the probability of them generating a group address as station
address).


> I am currently really unsure and looking in well-known IoT OS, if they
> look on this bit. But I didn't saw anything. Only that the most using
> the same like eth_random_addr address and fill with ff fe bit pattern.
> Maybe to operate with some virtual linux networking ethernet interfaces
> which are connected over slip and tun/tap and such things...

ff fe bit pattern?

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Lennert Buytenhek]

On Thu, May 28, 2015 at 04:53:51PM +0200, Alexander Aring wrote:

> Grml, I think I am getting too much confuses right now.

:-)


> > > Also compare your [0] with this document:
> > > 
> > > 	http://standards.ieee.org/develop/regauth/tut/eui48.pdf
> > > 
> > > And note how neither the EUI-48 nor the EUI-64 PDFs talk about group
> > > addresses -- this is because an EUI-{48,64} contains an OUI, and the
> > > OUI contains the scope/group bits, and so the documents explaining
> > > the EUI-{48,64} format are not the right place to discuss those bits,
> > > although they exist both in EUI-48 and in EUI-64 addresses.
> > > 
> > > Just the fact that 802.15.4 spec doesn't talk about multicast doesn't
> > > suddenly redefine the EUI-64 group bit as just another unicast address
> > > bit, in my humble opinion, but this is what Linux is currently doing.
> > >
> > 
> > The 802.15.4 spec doesn't also say any words about that the "extended
> > address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a
> > EUI-64 [1]. General question is "Is the extended-address in 802.15.4
> > really meaning an EUI-64 address?". Sorry for this newbie question, but
> > this is what I am asking myself now.
> > 
> > What I see is that the extended-addr is described as "The 64-bit (IEEE)
> > address assigned to the device." Which says to me it's an EUI-64, or?
> > 
> > But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't
> > deal with the 0x00..00.
> 
> forget this sentence. I mean this is true when extended_addr != EUI-64
> but I don't think that's true.

Right, OK, makes sense.


> > > From a hardware point of view, multicast packets should never be
> > > ACKed, so there is no need for the hardware to be aware of the active
> > > multicast addresses on this interface per se.  (We could theoretically
> > > pass the multicast address list for the interface to the hardware to
> > > allow doing frame filtering in hardware, but this does not affect
> > > operational correctness.)
> > 
> > So then we should also add a check of this bit at [0]? Then set the
> > ackreq bit to 0 if the bit is set?
> > 
> > > Whether we should be using EUI-64 group addresses on the "wire" for
> > > 802.15.4 for multicast (IPv6) traffic is another question, but using
> > > EUI-64 group addresses as station addresses just because the link
> > > layer doesn't define multicast functionality is wrong from my point
> > > of view.
> > 
> > When this address is invalid and the MAC layer doesn't use this bit.
> > Then we need to care that we drop all frames with the source address
> > with this bit. I also don't see that any transceiver with address
> > filtering enabled will drop this frame (okay they also don't filter 0x00..00
> > and 0xff...ff) frames.
> 
> I mean here how we should react globally about source address which have
> this bit set? When it's source address then we should drop it and
> destination address? I don't know. :-)

I don't think we can get away with changing our behavior to start being
strict about the source address group bit. :(

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Stefan Schmidt]

Hello.

On 29/05/15 05:19, Lennert Buytenhek wrote:
> On Thu, May 28, 2015 at 04:42:53PM +0200, Alexander Aring wrote:
>
>
>> I am currently really unsure and looking in well-known IoT OS, if they
>> look on this bit. But I didn't saw anything. Only that the most using
>> the same like eth_random_addr address and fill with ff fe bit pattern.
>> Maybe to operate with some virtual linux networking ethernet interfaces
>> which are connected over slip and tun/tap and such things...
> ff fe bit pattern?

What they do is mapping a EUI-48 to a EUI-64 following the guidelines from:

https://standards.ieee.org/develop/regauth/tut/eui48.pdf page 4

The two missing octets are filled in with either FF FE or FF FF. The 
padding happens after the first three bytes with the OUI and the rest of 
the EUI-48.

regards
Stefan Schmidt

Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Lennert Buytenhek]

On Fri, May 29, 2015 at 10:21:35AM +0200, Stefan Schmidt wrote:

> Hello.

Hi!


> >>I am currently really unsure and looking in well-known IoT OS, if they
> >>look on this bit. But I didn't saw anything. Only that the most using
> >>the same like eth_random_addr address and fill with ff fe bit pattern.
> >>Maybe to operate with some virtual linux networking ethernet interfaces
> >>which are connected over slip and tun/tap and such things...
> >ff fe bit pattern?
> 
> What they do is mapping a EUI-48 to a EUI-64 following the guidelines from:
> 
> https://standards.ieee.org/develop/regauth/tut/eui48.pdf page 4
> 
> The two missing octets are filled in with either FF
> FE or FF FF. The padding happens after the first
> three bytes with the OUI and the rest of the
> EUI-48.

Ah yes, I remember that, I just couldn't figure
out what the 'ff fe bit pattern' remark was
referring to -- thanks for clarifying. :)