Re: 6lowpan raw socket problems

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

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

- Alex