Re: 6lowpan raw socket problems

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

On Fri, Sep 19, 2014 at 10:57:32AM +0100, Simon Vincent wrote:
> 
> On 19/09/14 10:33, Alexander Aring wrote:
> >On Fri, Sep 19, 2014 at 09:27:05AM +0100, Simon Vincent wrote:
> >...
> >>>Yep, then you could try to test what I did there. Simple save the
> >>>address information in reserved skb data and then replacing data in
> >>>lowpan_xmit callback. This also solves the capture on lowpan interfaces.
> >>>
> >>>lowpan_xmit should be save to replacing the header.
> >>I am not 100% sure it is safe to replace the header at any point. How can
> >me, too. We need to check that.
> >
> >>you guarantee that the skb has been read by the user application RAW socket
> >>by this point? The user might not read the socket for seconds/minutes/hours.
> >>
> >no this can't happen. I need to dig into the code and running some
> >ftrace to check if this can work. The RAW socket should not involved here.
> >
> >My theory is:
> >
> >The current behaviour is maybe (Maybe, because it's an assumption).
> >
> >  - IPv6 neighbor discovery magic
> >    - calling create callback of header ops
> >      This callback is only there to add data there not replacing data.
> >      We do REPLACING the data so we can't parse the skb IPv6 header
> >      anymore.
> >    - After calling create callback of header ops IPv6 stack parse the
> >      IPv6 header data which is inside of skb. We already replaced the
> >      IPv6 header with 6LoWPAN header, so we can't parse it anymore but
> >      IPv6 does it. -> WEIRD things happen.
> >    - Finally lowpan interface calling xmit callback, this is at the end
> >      of doing Layer 3 things, so we should sure that nobody parse it there.
> >      What we do there is to queue the skb in the lower wpan interface.
> >
> >
> >The solution would be (maybe):
> >  - IPv6 neighbor discovery magic
> >    - calling create callback of header ops
> >      Putting necessary address information in skb reserved data. What
> >      this means, see below. We don't replace the IPv6 header.
> >    - After calling create callback of header ops IPv6 stack parse the
> >      IPv6 header data which is inside of skb. We don't replace the
> >      IPv6 header with 6LoWPAN header. -> all things are fine.
> >    - Finally lowpan interface calling xmit callback, this is at the end
> >      of doing Layer 3 things. Here we start to replacing IPv6 header
> >      with 6LoWPAN header. The thing is, we need the address information
> >      from create callback, that's why we saved it in skb reserved data.
> >
> 
> 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.
> 

Can't follow here, I mean inside the xmit callback there is no layer 3
(IPv6) parsing, etc. anymore. So skb_network_header parsing as IPv6
header can't occur here.

Can you send a RFC about your solution? Then it's maybe more clear for
me.

- Alex