Scenario: RPL network with two nodes, one root with the border router example with ethos and another as a normal single interface RPL router (gnrc_networking or microcoap_server). Border router reboots while other RPL routers are still alive -> BR routing messed up
PC address: 2001:16d8:ff00:645::2
BR address (wireless): 2001:16d8:ff00:8645:1016:4e54:8bab:4012
other node address: 2001:16d8:ff00:8645:1016:4e54:8af1:4012
The border router was started first, configured for ethos, then the following commands to set up radio and RPL on the BR:
ifconfig 6 set chan 0
ifconfig 6 set pan 1911
ifconfig 6 set page 2
rpl init 6
rpl root 0 2001:16d8:ff00:8645:1016:4e54:8bab:4012
Then I booted the wireless node and configured it similarly:
ifconfig 7 set chan 0
ifconfig 7 set pan 1911
ifconfig 7 set page 2
rpl init 7
After this, everything works, even IPv6 internet connectivity. I ran ping6 2600:: on the wireless node and it receives the replies correctly.
I then rebooted the BR node and did the same initialization commands above, however, I noticed that it joined the DODAG right after rpl init before the rpl root command. Now it is no longer working and the BR is trying to route packets via itself over the air, so ping6 2600:: from the BR results in the below packet:
0000 61 dc 0b 77 07 12 40 ab 8b 54 4e 16 12 12 40 ab a..w..@..TN...@.
0010 8b 54 4e 16 12 7a 00 3a 20 01 16 d8 ff 00 86 45 .TN..z.: ......E
0020 10 16 4e 54 8b ab 40 12 26 00 00 00 00 00 00 00 ..NT..@.&.......
0030 00 00 00 00 00 00 00 00 80 00 c8 70 00 55 00 01 ...........p.U..
0040 55 55 55 55 UUUU
Frame 887: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface 0
IEEE 802.15.4 Data, Dst: 12:16:4e:54:8b:ab:40:12, Src: 12:16:4e:54:8b:ab:40:12
Frame Control Field: 0xdc61, Frame Type: Data, Acknowledge Request, Intra-PAN, Destination Addressing Mode: Long/64-bit, Source Addressing Mode: Long/64-bit
.... .... .... .001 = Frame Type: Data (0x0001)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..1. .... = Acknowledge Request: True
.... .... .1.. .... = Intra-PAN: True
.... 11.. .... .... = Destination Addressing Mode: Long/64-bit (0x0003)
..01 .... .... .... = Frame Version: 1
11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
Sequence Number: 11
Destination PAN: 0x0777
Destination: 12:16:4e:54:8b:ab:40:12 (12:16:4e:54:8b:ab:40:12) <<<<<<<========= SIC!
Extended Source: 12:16:4e:54:8b:ab:40:12 (12:16:4e:54:8b:ab:40:12) <<<<<<<========= SIC!
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
.... .... ..00 .... = Source address mode: Inline (0x0000)
.... .... .... 0... = Multicast address compression: False
.... .... .... .0.. = Destination address compression: Stateless
.... .... .... ..00 = Destination address mode: Inline (0x0000)
Next header: ICMPv6 (0x3a)
Source: 2001:16d8:ff00:8645:1016:4e54:8bab:4012
Destination: 2600::
Internet Protocol Version 6, Src: 2001:16d8:ff00:8645:1016:4e54:8bab:4012, Dst: 2600::
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 12
Next header: ICMPv6 (58)
Hop limit: 64
Source: 2001:16d8:ff00:8645:1016:4e54:8bab:4012
Destination: 2600::
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xc870 [correct]
Identifier: 0x0055
Sequence: 1
[No response seen]
[Expert Info (Warn/Sequence): No response seen to ICMPv6 request in frame 887]
[No response seen to ICMPv6 request in frame 887]
[Severity level: Warn]
[Group: Sequence]
Data (4 bytes)
Data: 55555555
[Length: 4]
After the issue appears the fibroute command shows that the default route via the ethos interface was deleted (by joining the RPL DAG as a router?)
running fibroute add :: via fe80::1 dev 7 makes routing work on the BR again and I can yet again communicate between the PC and the 6lowpan network.
Scenario: RPL network with two nodes, one root with the border router example with ethos and another as a normal single interface RPL router (gnrc_networking or microcoap_server). Border router reboots while other RPL routers are still alive -> BR routing messed up
PC address: 2001:16d8:ff00:645::2
BR address (wireless): 2001:16d8:ff00:8645:1016:4e54:8bab:4012
other node address: 2001:16d8:ff00:8645:1016:4e54:8af1:4012
The border router was started first, configured for ethos, then the following commands to set up radio and RPL on the BR:
Then I booted the wireless node and configured it similarly:
After this, everything works, even IPv6 internet connectivity. I ran
ping6 2600::on the wireless node and it receives the replies correctly.I then rebooted the BR node and did the same initialization commands above, however, I noticed that it joined the DODAG right after
rpl initbefore therpl rootcommand. Now it is no longer working and the BR is trying to route packets via itself over the air, soping6 2600::from the BR results in the below packet:After the issue appears the fibroute command shows that the default route via the ethos interface was deleted (by joining the RPL DAG as a router?)
running
fibroute add :: via fe80::1 dev 7makes routing work on the BR again and I can yet again communicate between the PC and the 6lowpan network.