Hi, thanks for your reply. On Wed, Aug 06, 2014 at 09:40:28AM +0900, YOSHIFUJI Hideaki/吉藤英明 wrote: > Hi, > > Alexander Aring wrote: > >There exist no mapping between extended and short addresses. The global problem > >that the neighbor discovery cache handle the address length with a static addr_len > >value from net_device, this value should not be changed during runtime. > > > > > >To handle 6LoWPAN over IEEE 802.15.4 correctly we need to indicate that the neighbor > >discovery stores an extended or short address. > : > >My idea: > > > >Let addr_len to extended_address_length + 1. In the last byte we have a bit which > >indicate that is it a short address. If this bit isn't set we have an extended > >address. > > > >If we do that, we need some conversions about generating the ICMPv6 messages according > >to [1]. We can solve that with some hooks in net/ipv6/ndisc.c like the ndisc_mc_map > >function for mapping mac multicast addresses. > > > >Another idea to avoid hooks in net/ipv6/ndisc.c is to parse and rebuild the ICMPv6 > >header while replacing IPv6 with the 6LoWPAN header. > > Please avoid magling icmpv6/ipv6 bits as much as possible. > Okay. > >Please I need help and I need a solution which is also acceptable for mainline. > > We can have L2-specific private data per NCE, and 6lowpan uses ARPHRD_IEEE802154. First I need to clarify that we have two 6LoWPAN implementations, one for 802.15.4 and the other one for bluetooth. Each have some generic code inside of net/6lowpan. What we need for this neighbor discovery issue is 802.15.4 specific only. I think bluetooth 6LoWPAN can deal with the normal behaviour. That a 6lowpan device for ieee802.15.4 use ARPHRD_IEEE802154 is wrong, we need something like ARPHRD_IEEE802154_6LOWPAN, but this is another problem. I will introduce it, currently this is most wrong because wireshark thinks there are 802.15.4 frames but on this interface should only plain IPv6 and upper layers visible. But this is out of scope of this issue. I can't also use ARPHRD_6LOWPAN otherwise bluetooth will do these 802.15.4 specific things in neighbor discovery. > Please consider using it for L2 private data, if you need L2-speicic extra > information per NCE. okay, I will try to implement something which allow this and make _small_ changes according ARPHRD_... during runtime. I will send it as RFC and we can discuss about that. I will try to have a less of evaluating dev->type much as possible. - 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
