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
--
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
