Re: 6lowpan raw socket problems

[Alexander Aring <alex.aring@gmail.com>]

Hi Simon,

On Wed, Sep 17, 2014 at 02:30:22PM +0100, Simon Vincent wrote:
> I have been looking into this issue again and it looks like RPL packets
> cause the problem. It looks a bit like the header is not decompressed
> correctly.
> 

You mean now IPv6 header here? I think yes, there should no other header
compression running for this case currently.

> When I send a RPL packet I can see lowpan_header_compress is called which
> compresses the header. I can not find where the header is decompressed when
> the packet is received. By the time the packet gets to rawv6_recvmsg the src
> and dest addresses in the header are corrupt.
> 

Okay, you say here issues with source and destination addresses. I have
no idea now what's going on your side.

I need more information which types of addresses you use. Which kind of
address compression methods, note we don't support stateful address
compression but you are welcome to send patches. :-)

My idea is now, enable some more debug information while running
decompress/compress methods.

At [0], you could add "#define DEBUG" then you see more information
about the compression/uncompression while receiving/transmit. Don't know
if you already know about that.

Very simple is also to check if DAC or SAC bit in iphc1 is set. If this
is set you used stateful compression, which is not supported (should
occur a warning).

I don't know right your setup if you use linux<->linux this should never
happen. Other question is also, do you use short addresses? Handling of
short addresses, except the broadcast address is currently also not
supported. :-(

I can also not say that there is more bugs than this, Werner Almesberger
detected some issue about ICMPv6 payload size. Some issue with ICMPv6 payload
which are lesser than 4 bytes was filtered by kernel. That was wrong for
RPL... there was some crazy issue [1]. What I here want to say is, that
probaly IPv6 implementation can't also deal with it, it's hard to debug
I know. Use a little bit ctags for stepping into the code and instrument
some printk foo, more or later you will find it. :)

Sorry but I can't currently look more into this issue. Maybe simple add
the "#define DEBUG" into [1], then write some mail which information
from dmesg.

> Is this expected?
> 

No, normally all things should run fine. Otherwise you detect a bug. :-)

And of course you are also welcome to send patches for it. I know there
was some guy/girl which said the traffic class compression is broken,
but this is currently hard understandable code, need some time to
decrypt it, maybe a full rework for traffic class compression/decompress
is needed. Maybe some cases for traffic class will break your address
compression/decompression, overwriting some 6LoWPAN inline data.

- Alex

[0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/6lowpan/iphc.c?id=refs/tags/v3.17-rc5#n51
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1c53c8e870cdedb6fc9550f41c558bab45b5219