Re: 6lowpan raw socket problems

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

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