On Fri, Sep 19, 2014 at 01:00:02PM +0100, Simon Vincent wrote: > > On 19/09/14 12:45, Alexander Aring wrote: > >On Fri, Sep 19, 2014 at 12:27:54PM +0100, Simon Vincent wrote: > >>On 19/09/14 12:08, Alexander Aring wrote: > >>>On Thu, Sep 18, 2014 at 04:19:11PM +0200, Alexander Aring wrote: > >>>>On Thu, Sep 18, 2014 at 03:02:17PM +0100, Simon Vincent wrote: > >>>>>I have created a small test program that shows this problem. It looks like a > >>>>>race condition as sometimes the addresses are not corrupt. > >>>>> > >>>>Mhh maybe some used after freed and then we copy somewhere garbage sometimes. > >>>>Don't know right now. > >>>> > >>>>>It looks like if the RAW socket gets the packet before the packet hits the > >>>>>6lowpan layer the addresses are fine. If the packet hits the 6lowpan layer > >>>>>before the RAW socket gets the packet then the addresses are corrupt. > >>>>> > >>>>>The test program can be found here. > >>>>>https://github.com/xsilon/sockdebug > >>>>> > >>>>>I will continue debugging! > >>>>> > >>>>ok, good luck. > >>>> > >>>I gave this now a try, how can I see the issue now? > >>> > >>>I see on output: > >>> > >>>recv_raw_icmp[fe80:0:41:c863:cdab:ffff:bbaa:aaaa%lowpan0->?] > >>> > >>>this address doesn't exist in my network. > >>> > >>>I can also upload wpan wireshark logs and lowpan wireshark logs, if you > >>>like. > >>> > >>>In sockdebug I changed also "const char* src_string =" to one of my > >>>lowpan addresses. Simon are you still here to debug this issue with me? > >>>:-) > >>Yes this is the same error I am seeing. I find that sometimes the recv > >>address is correct but mostly you get the corrupt address as the ipv6 header > >>has been overwritten by our compressed 6lowpan header. > >> > >>If you comment out the 6lowpan header compression function it solves the > >>problem. > >okay, then I dig now into the issue why the address is garbage. > > > >>I am trying to understand how the network stack handles skbs. As it is a > >>multicast packet it will be sent out on 802.15.4, raw socket and any other > >>interfaces you have but it looks like in this case the interfaces all get a > >>skb pointing to the same data. Therefore when we replace the ipv6 header > >>with a compressed version everyone else still thinks there is a normal ipv6 > >>header still there and therefore gets corrupt data. Should each interface > >>get a copy of the data? E.g. the ethernet, wifi, 802.15.4 and raw socket all > >>get a copy of the skb data not a clone? > >> > >>Maybe normally each interface will get a copy of the skb so they can attach > >>their own mac header but in the case of the RAW socket they don't bother > >>doing a copy as they don't need to add a header for the socket. But then we > >>come along and destroy the ipv6 header!! > >> > >>Just a theory! > >> > >okay, there exists a lot of there. I know what you saying because the > >data buffer is shared there exist race conditions because some other skb > >has in the next step a 6LoWPAN header, if I understand that correctly. > > > Yes I think the problem is we are sharing the databuffer and modifying the > contents. We should probably be given a copy of the data buffer. I can't > find the code that decides if we get a copy or clone of the skb. > yea, IPv6 stack is complicated. :-) And if you found it, it would be complicated to make any change on it, we are only an adapation layer... All 6LoWPAN runtime decisions in IPv6 are bad and do some change. But the IPv6 are not evil, we can talk with them that we have something which works on both stacks and doesn't decrease much the performance of IPv6. If we have something like this then we have a mainline solution. > For example in ip6_finish_output2 because it is a multicast packet the skb > is cloned (so same data buffer) and sent to the loopback interface. This > loopback interface is going to expect the ipv6 header to be intact. > ok I will remember and check it. - 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
