6lowpan code / unused features?

[joakimeriksson]

Hello,

I am looking at cleaning up some parts of the 6lowpan code and I am interested to know if anyone is using the SICSLOWPAN_NH_COMPRESSOR at all? It is a way to compress other things than what is specified in the RFC's but since the RFC will likely not change that much at the moment and if noone is using that code I do think it should be removed (including old compression mechanism - HC1) to get the code easier to read and significantly shorter.

[g-oikonomou]

'No', not using the NH_COMPRESSOR. But to hijack your thread a little: doc/sicslowpan-doc.txt is pretty outdated, so if you could have a look at that one while you're at it that'd be great :)

[nvt]

A cleanup of the 6lowpan implementation would be appreciated! There is indeed some legacy code that can be removed, and many references to the Internet draft HC-06 instead of RFC 6282.

[joakimeriksson]

Yes, sure I can take a look at the docs too and also check the IPHC compressor towards RFC 6282 (which I think is ok) and then update references to HC-06 to be IPHC / RFC-6282 references instead.

[jnohlgard]

@joakimeriksson I have run into what I believe is an issue with the address decoding for 0 bit address when short 802.15.4 addressing is used.

An example 802.15.4 frame is included at the end of this post.

Wireshark displays the source address of the problematic packets as fe80::ff:fe00:ccbe while the Contiki debug printouts show the following message:

IPv6 packet received from fe80::cebe:0:0:0 to ff02::1a

The Wireshark behaviour is what I expect from reading the relevant RFC documents and from the look of the erroneous address I believe the Contiki 6lowpan source address decoding is unaware of 16 bit 802.15.4 addressing and uses it as if it were a 64 bit address with the tail-end 6 bytes set to 0.

Below is an example 802.15.4 frame which is misinterpreted by Contiki. Use text2pcap -l 230 packets.txt packets.pcap to generate a PCAP file for reading in Wireshark. (The frame is a RPL DIO message)

0000  41 88 0e 77 07 ff ff be cc 7a 3b 3a 1a 9b 01 2d ea 00 f0 01 00 90 01 00 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00 cc be 04 0e 00 07 0b 0a 00 00 01 00 00 00 00 ff 00 02

For reference, below is a packet dissection by Wireshark, low level protocols only, omitted some irrelevant fields for brevity:

No.     Time        Source                Destination           Protocol Length Info
     66 3772.429112 fe80::ff:fe00:ccbe    ff02::1a              ICMPv6   57     RPL Control (DODAG Information Object)

Frame 66: 57 bytes on wire (456 bits), 57 bytes captured (456 bits)
    Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
IEEE 802.15.4 Data, Dst: Broadcast, Src: 0xccbe
    Frame Control Field: Data (0x8841)
        .... .... .... .001 = Frame Type: Data (0x0001)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
    Sequence Number: 14
    Destination PAN: 0x0777
    Destination: 0xffff
    Source: 0xccbe
6LoWPAN
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003)
        .... .0.. .... .... = Next header: Inline
        .... ..10 .... .... = Hop limit: 64 (0x0002)
        .... .... 0... .... = Context identifier extension: False
        .... .... .0.. .... = Source address compression: Stateless
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 1... = Multicast address compression: True
        .... .... .... .0.. = Destination address compression: Stateless
        .... .... .... ..11 = Destination address mode: 8-bits inline (0x0003)
        [Source context: fe80:: (fe80::)]
        [Destination context: fe80:: (fe80::)]
    Next header: ICMPv6 (0x3a)
    Source: fe80::ff:fe00:ccbe (fe80::ff:fe00:ccbe)
    Destination: ff02::1a (ff02::1a)
Internet Protocol Version 6, Src: fe80::ff:fe00:ccbe (fe80::ff:fe00:ccbe), Dst: ff02::1a (ff02::1a)
    0110 .... = Version: 6
        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 44
    Next header: ICMPv6 (58)
    Hop limit: 64
    Source: fe80::ff:fe00:ccbe (fe80::ff:fe00:ccbe)
    Destination: ff02::1a (ff02::1a)
...

[joakimeriksson]

That is likely an issue for short addresses. We have mainly used long 802.15.4 addresses and the 6lowpan code probably assumes long addresses. I do think we have mainly used that for simplicity when auto-configuring IPv6 addresses (Prefix + MAC). I guess it would be fairly easy to fix that while doing some other cleanups to the code.

[joakimeriksson]

BTW: is there a good 6lowpan / pcap trace library somewhere? It would be very useful for testing if Contiki's 6lowpan code is doing the correct things (and maybe to develop a set of unit-tests on).