On Fri, Sep 19, 2014 at 01:50:05PM +0200, Alexander Aring wrote: > On Fri, Sep 19, 2014 at 01:45:49PM +0200, 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. > > > > funny, I see a pattern: > > recv_raw_icmp[fe80:0:41:c85d:cdab:ffff:bbaa:aaaa%lowpan0->?] > recv_raw_icmp[fe80:0:41:c85e:cdab:ffff:bbaa:aaaa%lowpan0->?] > recv_raw_icmp[fe80:0:41:c85f:cdab:ffff:bbaa:aaaa%lowpan0->?] > recv_raw_icmp[fe80:0:41:c860:cdab:ffff:bbaa:aaaa%lowpan0->?] > recv_raw_icmp[fe80:0:41:c861:cdab:ffff:bbaa:aaaa%lowpan0->?] > recv_raw_icmp[fe80:0:41:c862:cdab:ffff:bbaa:aaaa%lowpan0->?] > recv_raw_icmp[fe80:0:41:c863:cdab:ffff:bbaa:aaaa%lowpan0->?] > ^^ > > The ^^ is looking like there is some sequence number which is increasing. :-) > now compared with wireshark dump, it looks like that at :41:c8... begins the mac header. crazy... We come closer to the issue. - 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
