Re: 6lowpan raw socket problems

[Simon Vincent <simon.vincent@xsilon.com>]

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.

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!

Simon