RPL related issue list

[BytesGalore]

Here we can collect and discuss issues related to the RPL implementation

• wrong RPL all-RPL-nodes-address (cf RPL control messages have the wrong destination address #2490 and a solution PR rpl: use the all-RPL-nodes multicast address #2491, merged)
• wrong checksum calculation of RPL messages (sixlowpan: Invert local/universal bit in EUI-64 when forming IPv6 Interface Identifiers. #2497, merged)
• replies from RIOT RPL nodes are sent to the wrong address (sixlowpan: Broadcast message when neighbour not found in cache. #2504)
• using the objective function of1, mrhof does not seem to work as etx_beaconing is not initialized
• pass rpl_instance_t directly instead of its id rpl: pass rpl_instance_t directly instead of its id #2604
• handle multiple DODAGs
  • remove unnecessary check for multiple instances rpl: remove unnecessary check for multiple instances #2606
  • update routing table information for all dodags rpl: update routing table information for all dodags #2607 (depends on rpl: expose global rpl_dodags variable #2622)
  • make send_DAO aware of multiple dodags rpl: make send_DAO aware of multiple dodags #2608
  • make send_DIO aware of multiple dodags rpl: make send_DIO aware of multiple dodags #2609
  • remove some usages of rpl_get_my_dodag rpl: remove some usages of rpl_get_my_dodag #2610
  • expose global rpl_dodags variable rpl: expose global rpl_dodags variable #2622
  • check all dodags when receiving DIS messages rpl: check all dodags when receiving DIS messages #2624 (depends on rpl: expose global rpl_dodags variable #2622 rpl: make send_DIO aware of multiple dodags #2609)
  • remove global variable indicating the root node rpl: remove global variable indicating the root node #2625 (depends on rpl: expose global rpl_dodags variable #2622)
  • implement the which_dodag function of of0 rpl: implement the which_dodag function of of0 #2628
  • logic to switch between dodags rpl: logic to switch between dodags #2631
  • remove rpl_get_my_dodag() dependency in rpl_delete_all_parents() rpl: remove rpl_get_my_dodag() dependency in rpl_delete_all_parents() #2633
  • remove get_my_dodag dependency by passing the dodag as parameter rpl: remove get_my_dodag dependency by passing the dodag as parameter #2653
  • pass dodag to the rpl_find_parent function rpl: pass dodag to the rpl_find_parent function #2644
• root cannot send to nodes rpl: root cannot send to nodes #2642
• some RPL headers are not Doxygen documented RPL headers need documentation #2656

[cgundogan]

@BytesGalore great idea.
@gebart would be nice to see a dump :) as the problems might be in layers below (I can think of 6lowpan or 802.15.4 short/long address confusion here out of my head)

[jnohlgard]

@cgundogan I finally found the address confusion. See http://packetlife.net/blog/2008/aug/4/eui-64-ipv6/
There is a bug in lowpan.c in lowpan_iphc_decoding, around line 1355. We need to invert the EUI-64 local/universal bit, which is the 0x02 bit in the first byte.

[cgundogan]

This was also my first thought and I looked it up in [1]. But it states

A short IEEE 802.15.4 address is 16 bits in length. Short addresses
are mapped into the restricted space of IEEE EUI-64 addresses by
setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
address, and all other bits to zero. As a result, an IID generated
from a short address has the form:
0000:00ff:fe00:XXXX
where XXXX carries the short address. The universal/local bit is
zero to indicate local scope.

According to the last sentence, the u/l bit should be zero?

I think the rpl_udp example uses short addresses for 802.15.4 beacons, can you verify with wireshark?

[1] https://tools.ietf.org/html/rfc6282#page-12

[jnohlgard]

@cgundogan I was using Contiki as a root node for sending DIOs, it was using a 64 bit 802.15.4 source address (02:00:00:00:00:00:00:01)

[jnohlgard]

After modifying the EUI64 to IPv6 address translation to get RIOT to understand Contiki's compressed headers it now seems like Contiki is having some trouble translating RIOT's short addresses to EUI64. Contiki says: IPv6 packet received from fe80::cebe:0:0:0 to ff02::1a
while Wireshark says from fe80::ff:fe00:ccbe to ff02::1a

Contiki uses long addressing in most packets which may be the reason that I have not seen this problem before.

[jnohlgard]

Here is a packet capture of a Contiki RPL root (examples/ipv6/rpl-border-router) communicating with a RIOT RPL node (init n):
https://www.dropbox.com/s/nwyfy159rrjnijw/rpl-contiki-root-riot-node.pcap?dl=0

The capture is taken from a RIOT built with PR #2497 and #2491 applied

Noteworthy points:

• DAO messages sent back from RIOT to Contiki have the wrong ICMPv6 checksum, according to Wireshark: Checksum: 0xa68a [incorrect, should be 0xa78a] unclean build, fixed now.
• DAO message sent back from RIOT to Contiki is being sent to short 802.15.4 address 0x0001 instead of the original extended address 02:00:00:00:00:00:00:01
• DAO message sent back from RIOT to Contiki is sent to fe80::00ff:fe00:0001 instead of the address of the origin of the DIO message fe80::1 unclean build, fixed now.

Regarding the last point

using the objective function of1, mrhof does not seem to work as etx_beaconing is not initialized

Is this specific to the application (e.g. examples/rpl_udp) or should this happen in the network stack bring up in sys/net?

I have no idea where to start looking for this, is it a big task or a small task? Contiki uses MRHOF by default, but can be configured to use OF0 instead. I think it would be useful if RIOT also could work with both settings.

[LudwigKnuepfer]

Look at the capture in the cloud: https://www.cloudshark.org/captures/4b9b364dc2b8

[jnohlgard]

Sorry about that last pcap, I found out I had an unclean build, the broken ICMP checksum is fixed now.
I have updated the original file to a new capture. The destination 802.15.4 address is still wrong with a clean build.

Edit: Added a new cloud link: https://www.cloudshark.org/captures/f168849c67ed

[jnohlgard]

I traced the short address problem to sys/net/network_layer/sixlowpan/ip.c:126

The destination address is not found in the neighbour cache because the Contiki RPL root does not send any neighbour notices.

        if (next_hop == NULL) {
            DEBUG("Trying to find the next hop for %s\n", ipv6_addr_to_str(addr_str, IPV6_MAX_ADDR_STR_LEN, &packet->destaddr));

            if (ip_get_next_hop == NULL) {
                return -1;
            }

            ipv6_addr_t *dest = ip_get_next_hop(&packet->destaddr);

            if (dest == NULL) {
                return -1;
            }

            nce = ndp_get_ll_address(dest);

            if (nce == NULL
                || sixlowpan_lowpan_sendto(nce->if_id, &nce->lladdr,
                                           nce->lladdr_len, (uint8_t *) packet, length) < 0) {
                /* XXX: this is wrong, but until ND does work correctly,
                 *      this is the only way (aka the old way)*/
                uint16_t raddr = dest->uint16[7];
                sixlowpan_lowpan_sendto(0, &raddr, 2, (uint8_t *) packet, <------------- Here
                                        length);
                /* return -1; */
            }
        }

[cgundogan]

@gebart I just realized the following:
In a setup with two nodes (1 node + 1 root) [both using native, tap devices].
According to wireshark, the node sends DAOs from fe80::ff:fe00:1 to fe80::200:ff:fe00:2, although root's address is configured as fe80::ff:fe00:1. This results in a packet drop and therefore no routes are entered into the routing table by rpl. This might have to do something with the universal/local bit flipping we introduced earlier. Do you have any ideas how to fix this?

[jnohlgard]

@cgundogan I did not realize until #2508 but we need to go through the iphc encoding and EUI-64 generation to see where it goes wrong. I need to re-read the relevant RFCs to see how to do it correctly...

[jnohlgard]

@cgundogan I updated the checklist with your multiple DODAG implementation, could you complete the info if I missed anything?

[cgundogan]

@gebart thanks for adding my PRs. I completely forgot about this issue list (:

[jnohlgard]

@BytesGalore @cgundogan Do you know what is needed to get MRHOF (OF1) working?

[cgundogan]

@gebart I have no experience with our etx implementation, I am not aware of its state (does it run or not?). Maybe @Lotterleben can say more on this topic?

[Lotterleben]

@cgundogan @gebart Nope, sorry...

[OlegHahm]

I think one problem is that metric containers aren't implemented. @sarndt, can you provide any more details?

[sarndt]

The ETX metric had some problem with bugs in timers of RIOT when I implemented it. I don't know if those are still prevalent. Metric Containers should not be the problem, at least when I worked on RIOT, ETX was the default metric for RPL when there is no metric container.

It's true though, that metric containers were not implemented, which meant that only the default metric could be used.

[jnohlgard]

The RPL headers need some Doxygen love, added to task list

[jnohlgard]

I updated the list to reflect what has been merged so far.

[jnohlgard]

This list was referring to the old RPL implementation which has been discarded.