Re: 6lowpan raw socket problems

[Alexander Aring <alex.aring@gmail.com>]

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