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 -- 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
