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.
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. Please consider using it for L2 private data, if you need L2-speicic extra information per NCE. Regards, --yoshfuji -- 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
