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. -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
