Re: 6lowpan raw socket problems

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

On 19/09/14 12:45, 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.
>
>> 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!
>>
> okay, there exists a lot of there. I know what you saying because the
> data buffer is shared there exist race conditions because some other skb
> has in the next step a 6LoWPAN header, if I understand that correctly.
>
Yes I think the problem is we are sharing the databuffer and modifying 
the contents. We should probably be given a copy of the data buffer. I 
can't find the code that decides if we get a copy or clone of the skb.

For example in ip6_finish_output2 because it is a multicast packet the 
skb is cloned (so same data buffer) and sent to the loopback interface. 
This loopback interface is going to expect the ipv6 header to be intact.

Simon