6lowpan raw socket problems
Hi Alex,
It looks like the problem is internal to Linux. I am running on a single Linux box, outputting a RPL message which is put onto a 802154 fakelb driver. The RPL message is also picked up by the code in my application that is listening on a RAW socket. This is where the corrupt addresses are seen.
All addresses are local link. Short addressing is used for the broadcast address only. I am not using stateful compression.
Is the same buffer used for the 6lowpan and ipv6 or is a copy taken to do the ipv6 header compression? If so the message is output on the 802154 but first the ipv6 header is compressed. The message is also passed to my RAW ipv6 socket from the ipv6 layer using the same buffer which now contains the compressed header?
|---> recvmsg RAW skt
sendmsg RAW skt --->|
|---> 6lowpan/802.15.4My debug can see the header getting compressed at the 6lowpan layer but there is no receive debug triggered so the RAW socket is getting the message from the ipv6 layer.
Thanks
Simon
Quoted 64 lines · Alexander Aring
Hi Simon,
Quoted 4 lines · Simon Vincent
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.
Quoted 5 lines
When I send a RPL packet I can see
lowpan_header_compressis 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 torawv6_recvmsgthe 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.
Quoted 2 lines
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