From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com ([74.125.82.171]:34188 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756624AbaISMAC (ORCPT ); Fri, 19 Sep 2014 08:00:02 -0400 Received: by mail-we0-f171.google.com with SMTP id p10so2378249wes.16 for ; Fri, 19 Sep 2014 05:00:00 -0700 (PDT) Date: Fri, 19 Sep 2014 13:59:55 +0200 From: Alexander Aring Subject: Re: 6lowpan raw socket problems Message-ID: <20140919115954.GA22963@omega> References: <20140918085433.GC3774@omega> <541A9FD3.2030104@xsilon.com> <20140918094401.GB4350@omega> <20140918094501.GC4350@omega> <541AE5E9.3000407@xsilon.com> <20140918141911.GA9262@omega> <20140919110854.GA21364@omega> <541C133A.7010000@xsilon.com> <20140919114549.GA22396@omega> <20140919115005.GB22396@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140919115005.GB22396@omega> Sender: linux-wpan-owner@vger.kernel.org List-ID: To: Simon Vincent Cc: linux-wpan@vger.kernel.org, werner@almesberger.net 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