Re: 6lowpan status

Re: 6lowpan status

[Alexander Aring]

Hi,

On Mon, Sep 01, 2014 at 01:36:14PM +0300, Jukka Rissanen wrote:
> Hi Alex,
> 
> I saw your RFC mail (9 Aug) about generic compression layer. Was there
> any functionality changes by this RFC or was it just refactoring the
> code?
> 

It's not just refactoring. The point is that there are many of RFC's
outside which declare a next header compession format (like UDP). UDP is
the only one next header compression which we currenlty support. If we
don't add a layer to add a new header compression format, all people
hack this into the iphc.c file. I don't know what you think about this
but I really don't like that.

This code adds a layer for this and supports all other known next header
compression formats in the way that we drop the packets afterwards
instead of deliver garabage to next layer (IPv6).

The layer avoids that everybody hacks static code into iphc file.

Please let me know if this is okay for you, then I will send a v2 with
changes.

> Anyway, looks ok to me although I just browsed quickly through the code,
> did not really review it :) Just wondering do we need more
> subdirectories under 6lowpan or could we just put everything into
> 6lowpan dir (just to keep it simple)? No big preference here thou.
> 

Don't know, but there is a unkown number of possible next header compression
formats outside, we should split it in a new subdirectorie. What I
actually mean, don't hack every next header compression format in a
single file.

For address compression/uncompression this is fine, there is no unknown
numbers of compression ways.

I know only IPHC and HC1. HC1 should be support for receiving side and
it's obsolete, but this is rfc 4944 so it's only related to 802.15.4.

Some or later we need to add support for this, but this should not used
by bluetooth 6LoWPAN.

> I saw the mail from Varka Bhadram (6 Aug) about RFC 6775 support. That
> looked interesting. Did you get the code from him (if yes, could you
> also send it to me)? Do you know why this guy have not send this stuff
> to upstream?
> 

The 802.15.4 mac layer has some neighbor discovery issues which are not
solved currently. It's about two kinds of mac addresses, for bluetooth
it should be fine. A small description about this problem is here [1].

We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer
and this isn't easy. Everything what we do on runtime decisions makes
the IPv6 stack slower and we should avoid that.



I currently working on a big rework of the 802.15.4 layer and will try
to bring this mainline at end of this month. Our mac layer is currenlty
in an not useable state. :(

I don't have time to make some effort after IPv6, currently I work on
the rework and will solve the two kind mac addresses issues with the
neighbor discovery cache, then we are in some state which we don't have
some broken support of functionality.


Maybe simple talk with Varka about what he did there, because I don't
really know what he exactly did there. The code what I saw isn't
mainline able. [0] What I know that RFC 6775 and the actually
implementation need to handle the two kinds of mac addresses (which is
broken currenlty) and need support of context based address compression.

I don't have time to add support for this. I need to rescue the 802.15.4
layer. Sorry! Maybe after that... or maybe somebody will do this work.
It sounds for me crazy to support RFC6775 which has dependencies on
other functionality which we doesn't support right now. For bluetooth
the mac layer works great, we only needs support for context based
address compression then.


I CC the new mailinglist for IEEE 802.15.4/IEEE 802.15.4 6LoWPAN
"linux-wpan" and bluetooth. We should not talk about this under the
hood.

- Alex

[0] https://www.mail-archive.com/linux-zigbee-devel%40lists.sourceforge.net/msg02018.html
[1] http://www.spinics.net/lists/netdev/msg291767.html

Re: 6lowpan status

[Jukka Rissanen]

Hi Alex,

On ma, 2014-09-01 at 13:38 +0200, Alexander Aring wrote:
> Hi,
> 
> On Mon, Sep 01, 2014 at 01:36:14PM +0300, Jukka Rissanen wrote:
> > Hi Alex,
> > 
> > I saw your RFC mail (9 Aug) about generic compression layer. Was there
> > any functionality changes by this RFC or was it just refactoring the
> > code?
> > 
> 
> It's not just refactoring. The point is that there are many of RFC's
> outside which declare a next header compession format (like UDP). UDP is
> the only one next header compression which we currenlty support. If we
> don't add a layer to add a new header compression format, all people
> hack this into the iphc.c file. I don't know what you think about this
> but I really don't like that.
> 
> This code adds a layer for this and supports all other known next header
> compression formats in the way that we drop the packets afterwards
> instead of deliver garabage to next layer (IPv6).
> 
> The layer avoids that everybody hacks static code into iphc file.

Ok, sounds like a plan.

> 
> Please let me know if this is okay for you, then I will send a v2 with
> changes.

Sure, just send new version.

> 
> > Anyway, looks ok to me although I just browsed quickly through the code,
> > did not really review it :) Just wondering do we need more
> > subdirectories under 6lowpan or could we just put everything into
> > 6lowpan dir (just to keep it simple)? No big preference here thou.
> > 
> 
> Don't know, but there is a unkown number of possible next header compression
> formats outside, we should split it in a new subdirectorie. What I
> actually mean, don't hack every next header compression format in a
> single file.

I was not really thinking that all the stuff would be in single file. I
was just pondering is there really a need for sub-directory, after all
the number of files in net/6lowpan directory is currently very small so
one option could be to put the nhc files directly into 6lowpan directory
(and perhaps adding them nhc_ prefix). Anyway, this is minor thing and I
am fine with having sub-directories.

> 
> For address compression/uncompression this is fine, there is no unknown
> numbers of compression ways.
> 
> I know only IPHC and HC1. HC1 should be support for receiving side and
> it's obsolete, but this is rfc 4944 so it's only related to 802.15.4.
> 
> Some or later we need to add support for this, but this should not used
> by bluetooth 6LoWPAN.
> 
> > I saw the mail from Varka Bhadram (6 Aug) about RFC 6775 support. That
> > looked interesting. Did you get the code from him (if yes, could you
> > also send it to me)? Do you know why this guy have not send this stuff
> > to upstream?
> > 
> 
> The 802.15.4 mac layer has some neighbor discovery issues which are not
> solved currently. It's about two kinds of mac addresses, for bluetooth
> it should be fine. A small description about this problem is here [1].
> 
> We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer
> and this isn't easy. Everything what we do on runtime decisions makes
> the IPv6 stack slower and we should avoid that.

Yep, agreed.

> 
> 
> 
> I currently working on a big rework of the 802.15.4 layer and will try
> to bring this mainline at end of this month. Our mac layer is currenlty
> in an not useable state. :(
> 
> I don't have time to make some effort after IPv6, currently I work on
> the rework and will solve the two kind mac addresses issues with the
> neighbor discovery cache, then we are in some state which we don't have
> some broken support of functionality.
> 
> 
> Maybe simple talk with Varka about what he did there, because I don't
> really know what he exactly did there. The code what I saw isn't
> mainline able. [0] What I know that RFC 6775 and the actually
> implementation need to handle the two kinds of mac addresses (which is
> broken currenlty) and need support of context based address compression.
> 
> I don't have time to add support for this. I need to rescue the 802.15.4
> layer. Sorry! Maybe after that... or maybe somebody will do this work.
> It sounds for me crazy to support RFC6775 which has dependencies on
> other functionality which we doesn't support right now. For bluetooth
> the mac layer works great, we only needs support for context based
> address compression then.

Ok. Currently I am also busy with some other stuff but I try to find
some time to investigate the RFC6775 more. Cannot really promise any
dates etc.

> 
> 
> I CC the new mailinglist for IEEE 802.15.4/IEEE 802.15.4 6LoWPAN
> "linux-wpan" and bluetooth. We should not talk about this under the
> hood.
> 
> - Alex
> 
> [0] https://www.mail-archive.com/linux-zigbee-devel%40lists.sourceforge.net/msg02018.html
> [1] http://www.spinics.net/lists/netdev/msg291767.html


Cheers,
Jukka

Re: 6lowpan status

[Alexander Aring]

Hi Jukka,

On Tue, Sep 02, 2014 at 09:08:10AM +0300, Jukka Rissanen wrote:
> Hi Alex,
> 
> On ma, 2014-09-01 at 13:38 +0200, Alexander Aring wrote:
> > Hi,
> > 
> > On Mon, Sep 01, 2014 at 01:36:14PM +0300, Jukka Rissanen wrote:
> > > Hi Alex,
> > > 
> > > I saw your RFC mail (9 Aug) about generic compression layer. Was there
> > > any functionality changes by this RFC or was it just refactoring the
> > > code?
> > > 
> > 
> > It's not just refactoring. The point is that there are many of RFC's
> > outside which declare a next header compession format (like UDP). UDP is
> > the only one next header compression which we currenlty support. If we
> > don't add a layer to add a new header compression format, all people
> > hack this into the iphc.c file. I don't know what you think about this
> > but I really don't like that.
> > 
> > This code adds a layer for this and supports all other known next header
> > compression formats in the way that we drop the packets afterwards
> > instead of deliver garabage to next layer (IPv6).
> > 
> > The layer avoids that everybody hacks static code into iphc file.
> 
> Ok, sounds like a plan.
> 
> > 
> > Please let me know if this is okay for you, then I will send a v2 with
> > changes.
> 
> Sure, just send new version.
> 

ok.

> > 
> > > Anyway, looks ok to me although I just browsed quickly through the code,
> > > did not really review it :) Just wondering do we need more
> > > subdirectories under 6lowpan or could we just put everything into
> > > 6lowpan dir (just to keep it simple)? No big preference here thou.
> > > 
> > 
> > Don't know, but there is a unkown number of possible next header compression
> > formats outside, we should split it in a new subdirectorie. What I
> > actually mean, don't hack every next header compression format in a
> > single file.
> 
> I was not really thinking that all the stuff would be in single file. I
> was just pondering is there really a need for sub-directory, after all
> the number of files in net/6lowpan directory is currently very small so
> one option could be to put the nhc files directly into 6lowpan directory
> (and perhaps adding them nhc_ prefix). Anyway, this is minor thing and I
> am fine with having sub-directories.
> 

ok. I that was the behaviour in one of my first series. I will change it
according to that. I agree with you here.

> > 
> > For address compression/uncompression this is fine, there is no unknown
> > numbers of compression ways.
> > 
> > I know only IPHC and HC1. HC1 should be support for receiving side and
> > it's obsolete, but this is rfc 4944 so it's only related to 802.15.4.
> > 
> > Some or later we need to add support for this, but this should not used
> > by bluetooth 6LoWPAN.
> > 
> > > I saw the mail from Varka Bhadram (6 Aug) about RFC 6775 support. That
> > > looked interesting. Did you get the code from him (if yes, could you
> > > also send it to me)? Do you know why this guy have not send this stuff
> > > to upstream?
> > > 
> > 
> > The 802.15.4 mac layer has some neighbor discovery issues which are not
> > solved currently. It's about two kinds of mac addresses, for bluetooth
> > it should be fine. A small description about this problem is here [1].
> > 
> > We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer
> > and this isn't easy. Everything what we do on runtime decisions makes
> > the IPv6 stack slower and we should avoid that.
> 
> Yep, agreed.
> 

That's the big challenge to make an acceptable mainline solution. :-)

At the end it should be acked by IPv6 community, they should scream if a
solution makes runtime decisions which slower down the stack too much.

> > 
> > 
> > 
> > I currently working on a big rework of the 802.15.4 layer and will try
> > to bring this mainline at end of this month. Our mac layer is currenlty
> > in an not useable state. :(
> > 
> > I don't have time to make some effort after IPv6, currently I work on
> > the rework and will solve the two kind mac addresses issues with the
> > neighbor discovery cache, then we are in some state which we don't have
> > some broken support of functionality.
> > 
> > 
> > Maybe simple talk with Varka about what he did there, because I don't
> > really know what he exactly did there. The code what I saw isn't
> > mainline able. [0] What I know that RFC 6775 and the actually
> > implementation need to handle the two kinds of mac addresses (which is
> > broken currenlty) and need support of context based address compression.
> > 
> > I don't have time to add support for this. I need to rescue the 802.15.4
> > layer. Sorry! Maybe after that... or maybe somebody will do this work.
> > It sounds for me crazy to support RFC6775 which has dependencies on
> > other functionality which we doesn't support right now. For bluetooth
> > the mac layer works great, we only needs support for context based
> > address compression then.
> 
> Ok. Currently I am also busy with some other stuff but I try to find
> some time to investigate the RFC6775 more. Cannot really promise any
> dates etc.
> 

Ok, null problem.

- Alex

Re: 6lowpan status

[Alexander Aring]

> > > 
> > > The 802.15.4 mac layer has some neighbor discovery issues which are not
> > > solved currently. It's about two kinds of mac addresses, for bluetooth
> > > it should be fine. A small description about this problem is here [1].
> > > 
> > > We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer
> > > and this isn't easy. Everything what we do on runtime decisions makes
> > > the IPv6 stack slower and we should avoid that.
> > 
> > Yep, agreed.
> > 
> 
> That's the big challenge to make an acceptable mainline solution. :-)
> 
> At the end it should be acked by IPv6 community, they should scream if a
> solution makes runtime decisions which slower down the stack too much.
> 

btw. I need L2 data in the neighbor discovery cache to handle the "two
kinds mac addresses". I will try to find a way after the rework of the mac
layer. This was discussed at [0].

- Alex

[0] http://marc.info/?l=linux-netdev&m=140724093516806&w=2

6lowpan raw socket problems

[Simon Vincent]

I am having problems with raw sockets on a 6lowpan 802.15.4 interface. 
The code works correctly on an ethernet ipv6 interface but not on a 
6lowpan interface. In the 6lowpan interface I receive packets but I find 
the src and dest addresses are incorrect.

I open the socket like this:
socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);

Add options for IPV6_RECVPKTINFO, IPV6_CHECKSUM, IPV6_RECVHOPLIMIT.

I then receive a packet using recvmsg and attempt to get the source 
address. The source address is rubbish. Also trying to get the 
destination address from IPV6_PKTINFO using CMSG_FIRSTHDR results in 
rubbish.

Can anyone explain why? Is there something different I have to do when 
using 802.15.4 and 6lowpan?

Regards
Simon

Re: 6lowpan raw socket problems

[Alexander Aring]

Hi Simon,

On Tue, Sep 02, 2014 at 03:21:56PM +0100, Simon Vincent wrote:
> I am having problems with raw sockets on a 6lowpan 802.15.4 interface. The
> code works correctly on an ethernet ipv6 interface but not on a 6lowpan
> interface. In the 6lowpan interface I receive packets but I find the src and
> dest addresses are incorrect.
> 
> I open the socket like this:
> socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
> 
> Add options for IPV6_RECVPKTINFO, IPV6_CHECKSUM, IPV6_RECVHOPLIMIT.
> 
> I then receive a packet using recvmsg and attempt to get the source address.
> The source address is rubbish. Also trying to get the destination address
> from IPV6_PKTINFO using CMSG_FIRSTHDR results in rubbish.
> 
> Can anyone explain why? Is there something different I have to do when using
> 802.15.4 and 6lowpan?
> 

Can you please send a test programm for this as example? Then I/We will
look at why this happen.

I think this would be the best to find why you have this issue. Doesn't
need to be the full program only a small example.


What I can say actually is:
To send ICMPv6 packets from userspace you need RAW-Sockets. This is how
ping6 do it and ping6 works on my side. Maybe there is a issue because
some of your sockopts.

- Alex

Re: 6lowpan raw socket problems

[Simon Vincent]

The program can be found at this github. branch all_fixes.
https://github.com/smee204/unstrung/tree/all_fixes

The socket is created in iface.cpp network_interface::setup()
The receive problem is in iface.cpp network_interface::receive(const 
time_t now)

Thanks

Simon

On 02/09/14 15:43, Alexander Aring wrote:
> Hi Simon,
>
> On Tue, Sep 02, 2014 at 03:21:56PM +0100, Simon Vincent wrote:
>> I am having problems with raw sockets on a 6lowpan 802.15.4 interface. The
>> code works correctly on an ethernet ipv6 interface but not on a 6lowpan
>> interface. In the 6lowpan interface I receive packets but I find the src and
>> dest addresses are incorrect.
>>
>> I open the socket like this:
>> socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
>>
>> Add options for IPV6_RECVPKTINFO, IPV6_CHECKSUM, IPV6_RECVHOPLIMIT.
>>
>> I then receive a packet using recvmsg and attempt to get the source address.
>> The source address is rubbish. Also trying to get the destination address
>> from IPV6_PKTINFO using CMSG_FIRSTHDR results in rubbish.
>>
>> Can anyone explain why? Is there something different I have to do when using
>> 802.15.4 and 6lowpan?
>>
> Can you please send a test programm for this as example? Then I/We will
> look at why this happen.
>
> I think this would be the best to find why you have this issue. Doesn't
> need to be the full program only a small example.
>
>
> What I can say actually is:
> To send ICMPv6 packets from userspace you need RAW-Sockets. This is how
> ping6 do it and ping6 works on my side. Maybe there is a issue because
> some of your sockopts.
>
> - Alex

Re: 6lowpan raw socket problems

[Alexander Aring]

Hi,

On Tue, Sep 02, 2014 at 03:51:13PM +0100, Simon Vincent wrote:
> The program can be found at this github. branch all_fixes.
> https://github.com/smee204/unstrung/tree/all_fixes
> 
> The socket is created in iface.cpp network_interface::setup()
> The receive problem is in iface.cpp network_interface::receive(const time_t
> now)
> 
Thanks I will look at it, but I mean a small example not a complete RPL
framework. Nevertheless I think this is a good start to add a testing
framework into the wpan-tools. I will create a small test application
for raw sockets and different settings of sockopts.

6LoWPAN is only an adaptation layer we don't have any changes in the
IPv6 stack. Maybe you can also say something about which IPv6 address
type it was with the address compression according the address type?

For example link-local which is based on the mac address (SLAAC). I
already said we have issues with short addresses and 802.15.4 6LoWPAN. I
hope you don't want to try something with short addresses.

- Alex

Re: 6lowpan raw socket problems

[Alexander Aring]

Hi Simon,

I saw this right now [0].

This is how an eui48 is converted to eui64. But we have already a
neui64. Are you sure this code check on this?

Normally it should check if the dev addr_len is 64 bit long, then it's a
eui64 address.

I don't see any test on this. That's why it works on a ethernet device
and not on a 802.15.4 lowpan device type.

- Alex

[0] https://github.com/smee204/unstrung/blob/all_fixes/lib/libndmgmt/iface.cpp#L91

Re: 6lowpan raw socket problems

[Simon Vincent]

This is not a problem. There is a fix elsewhere for that.

I am using local-link addresses.

I am seeing funny things like:
lowpan0: received packet from fe80::203:9a00:41:c864 -> 
7707:ffff:300:0:9a:300:7b3b:3a1a

Src address fe80::203:9a00:41:c864 does not exist on the network and 
destination address 7707:ffff:300:0:9a:300:7b3b:3a1a does not.

I will play around with different socket options and see if that makes a 
difference.

Simon

On 02/09/14 16:37, Alexander Aring wrote:
> Hi Simon,
>
> I saw this right now [0].
>
> This is how an eui48 is converted to eui64. But we have already a
> neui64. Are you sure this code check on this?
>
> Normally it should check if the dev addr_len is 64 bit long, then it's a
> eui64 address.
>
> I don't see any test on this. That's why it works on a ethernet device
> and not on a 802.15.4 lowpan device type.
>
> - Alex
>
> [0] https://github.com/smee204/unstrung/blob/all_fixes/lib/libndmgmt/iface.cpp#L91

Re: 6lowpan raw socket problems

[Alexander Aring]

On Tue, Sep 02, 2014 at 05:06:32PM +0100, Simon Vincent wrote:
> This is not a problem. There is a fix elsewhere for that.
> 
> I am using local-link addresses.
> 
> I am seeing funny things like:
> lowpan0: received packet from fe80::203:9a00:41:c864 ->
> 7707:ffff:300:0:9a:300:7b3b:3a1a
> 
> Src address fe80::203:9a00:41:c864 does not exist on the network and
> destination address 7707:ffff:300:0:9a:300:7b3b:3a1a does not.
> 

Where do you capture this? You know that wireshark on a lowpan interface
is broken?

- Alex

Re: 6lowpan raw socket problems

[Martin Townsend]

On 02/09/14 17:26, Alexander Aring wrote:
> On Tue, Sep 02, 2014 at 05:06:32PM +0100, Simon Vincent wrote:
>> This is not a problem. There is a fix elsewhere for that.
>>
>> I am using local-link addresses.
>>
>> I am seeing funny things like:
>> lowpan0: received packet from fe80::203:9a00:41:c864 ->
>> 7707:ffff:300:0:9a:300:7b3b:3a1a
>>
>> Src address fe80::203:9a00:41:c864 does not exist on the network and
>> destination address 7707:ffff:300:0:9a:300:7b3b:3a1a does not.
>>
> Where do you capture this? You know that wireshark on a lowpan interface
> is broken?
>
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hi Alex,

I'm working with Simon and these are from printf statements, we've 
stepped through the code and seen the same problem.

It would be nice to have a better testing environment, you mentioned 
that you have a virtual setup, does this allow for multiple nodes 
sending receiving packets like the contiki one? if so do you have 
instructions on how to setup?

Many Thanks,
Martin.

Re: 6lowpan raw socket problems

[Alexander Aring]

On Tue, Sep 02, 2014 at 07:53:50PM +0100, Martin Townsend wrote:
> On 02/09/14 17:26, Alexander Aring wrote:
> >On Tue, Sep 02, 2014 at 05:06:32PM +0100, Simon Vincent wrote:
> >>This is not a problem. There is a fix elsewhere for that.
> >>
> >>I am using local-link addresses.
> >>
> >>I am seeing funny things like:
> >>lowpan0: received packet from fe80::203:9a00:41:c864 ->
> >>7707:ffff:300:0:9a:300:7b3b:3a1a
> >>
> >>Src address fe80::203:9a00:41:c864 does not exist on the network and
> >>destination address 7707:ffff:300:0:9a:300:7b3b:3a1a does not.
> >>
> >Where do you capture this? You know that wireshark on a lowpan interface
> >is broken?
> >
> >- Alex
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Hi Alex,
> 
> I'm working with Simon and these are from printf statements, we've stepped
> through the code and seen the same problem.
> 
> It would be nice to have a better testing environment, you mentioned that
> you have a virtual setup, does this allow for multiple nodes sending
> receiving packets like the contiki one? if so do you have instructions on
> how to setup?
> 

for testing you could use fakelb or tony's serial virtual interface [0].
I didn't test both of them, but we need some testing interface of
course.

The virtual serial interface require the serial driver.

Sorry for my late reply.

[0] https://github.com/tcheneau/virtual-ieee802154-serial

Re: 6lowpan raw socket problems

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

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.

Is this expected?

Regards

Simon

On 08/09/14 11:43, Alexander Aring wrote:
> On Tue, Sep 02, 2014 at 07:53:50PM +0100, Martin Townsend wrote:
>> On 02/09/14 17:26, Alexander Aring wrote:
>>> On Tue, Sep 02, 2014 at 05:06:32PM +0100, Simon Vincent wrote:
>>>> This is not a problem. There is a fix elsewhere for that.
>>>>
>>>> I am using local-link addresses.
>>>>
>>>> I am seeing funny things like:
>>>> lowpan0: received packet from fe80::203:9a00:41:c864 ->
>>>> 7707:ffff:300:0:9a:300:7b3b:3a1a
>>>>
>>>> Src address fe80::203:9a00:41:c864 does not exist on the network and
>>>> destination address 7707:ffff:300:0:9a:300:7b3b:3a1a does not.
>>>>
>>> Where do you capture this? You know that wireshark on a lowpan interface
>>> is broken?
>>>
>>> - Alex
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Hi Alex,
>>
>> I'm working with Simon and these are from printf statements, we've stepped
>> through the code and seen the same problem.
>>
>> It would be nice to have a better testing environment, you mentioned that
>> you have a virtual setup, does this allow for multiple nodes sending
>> receiving packets like the contiki one? if so do you have instructions on
>> how to setup?
>>
> for testing you could use fakelb or tony's serial virtual interface [0].
> I didn't test both of them, but we need some testing interface of
> course.
>
> The virtual serial interface require the serial driver.
>
> Sorry for my late reply.
>
> [0] https://github.com/tcheneau/virtual-ieee802154-serial

Re: 6lowpan raw socket problems

[Alexander Aring]

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

Re: 6lowpan raw socket problems

[Alexander Aring]

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.

- Alex

[0] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan_rtnl.c#L456
[1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/fakelb.c#L81

Re: 6lowpan raw socket problems

[Alexander Aring]

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

Re: 6lowpan raw socket problems

[Simon Vincent]

We are using kernel 3.16 from davem net-next.

On 17/09/14 17:17, Alexander Aring wrote:
> 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