Hi, On Wed, Sep 17, 2014 at 06:03:53PM +0200, Alexander Aring wrote: > On Wed, Sep 17, 2014 at 04:33:49PM +0100, Simon Vincent wrote: > > 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.4 > > > > My debug can see the header getting compressed at the 6lowpan layer but > > <--- compressed means tx working and no rx. > > > there is no receive debug triggered so the RAW socket is getting the message > > from the ipv6 layer. > > > > mhhh, I have a theory. The linux networking stack is too clever. It see's > that these addresses are on the _same_ HOST and running it only one some > loopback interfaces. It's like ping6 ::1 on a lowpan interface, if you > want to do that, we never replace the IPv6 header with an 6LoWPAN header > because the current behaviour doesn't send it to the lower layers. > In this case "linux networking stack" see's "ahhh the same host -> doing > magic optimization". Then the IPv6 stack doesn't call the necessary > callbacks to do 6LoWPAN magic. > > Please instrument some driver layer of fakelb driver [1] then we can check > this theory, When you instrument some printk's at driver layer we can > see if your frames ever reached the lower layer. I am right not sure if > this could be true, I never tested so much the fakelb driver. > > Also please instrument this function [0], it's necessary to run > decompression when receiving. If my theory is true, then it's a > complicated issue and don't know right now a easy workaround. > I also remembered an other guy/girl which had some issues with 6lowpan and fakelb driver, but I did a quick test and it worked for me. Which kernel version do you using, net-next kernel? - Alex -- 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
