Re: 6lowpan raw socket problems

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

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