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 -- 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
