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
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
