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