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