Hi Simon, On Fri, Sep 19, 2014 at 12:15:34PM +0200, Alexander Aring wrote: ... > > > > It does not look like it is safe to do it at xmit callback either. I have > > added debug printing out skb_shinfo(skb)->dataref in the compress function > > as well as the lowpan_xmit function and there are 3 refs to the data at both > > points. This makes sense as the packet would be sent to the > > 802.15.4/ethernet/rawsocket as it is a multicast packet. > > I think the only solution is to do a full copy of the packet in the 6lowpan > > layer. Then we can modify the headers as much as we like. I know there is an > > overhead doing this but I can't see another way of avoiding this issue. > > > I found now the "dev_hard_header" call inside the IPv6 implementation [0]. It's a wrapper to call the create callback of header ops. So what I understand about the issue that, somebody assume that there is still an IPv6 header and not 6LoWPAN header. But we replacing data there so some implementation will parse garbage. [0] shows three function which call dev_hard_header: - neigh_compat_output - neigh_resolve_output - neigh_connected_output So these three we need to look at it and see if there is some code which parse an IPv6 header afterwards. Right? I will try to do some grep magic and find a case when this happens. - Alex [0] http://lxr.free-electrons.com/source/net/core/neighbour.c#L1294 -- 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
