Problem with RPL hopping

Help
#1

Hi - I have two nodes spaced apart so they can communicate with each other but the farthest (can’t talk to the BR. So it is a test of RPL linking them up. The first node (:6769) is a samr30 xpro up a tree! running https://github.com/kmartinez/myRIOT/tree/master/gnrc_networking The furthest away (5a6e) is a custom samr30 running https://github.com/kmartinez/myRIOT/tree/master/3yp_node_coap.

The border router says:

nib route
2001:fdfd::/64 dev #5
2001:fdfd::bcf1:5134:4751:6769/128 via fe80::bcf1:5134:4751:6769 dev #5
2001:fdfd::ec26:3905:43b7:5a6e/128 via fe80::bcf1:5134:4751:6769 dev #5
default* via fe80::1 dev #6

Which looks perfect.

the furthest away says:

2020-12-10 16:24:56,548 #  nib neigh
2020-12-10 16:24:56,551 # fe80::bcf1:5134:4751:6769 dev #5 lladdr BE:F1:51:34:47:51:67:69 router REACHABLE GC

----- looks good!

020-12-10 16:25:17,650 #  rpl
2020-12-10 16:25:17,667 # instance table:	[X]
2020-12-10 16:25:17,668 # parent table:	[X]	[ ]	[ ]
2020-12-10 16:25:17,668 #
2020-12-10 16:25:17,670 # instance [0 | Iface: 5 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
2020-12-10 16:25:17,683 # 	dodag [2001:fdfd::58a4:8450:8511:6445 | R: 768 | OP: Router | PIO: on | TR(I=[8,20], k=10, c=5, TC=2278s)]
2020-12-10 16:25:17,685 # 		parent [addr: fe80::bcf1:5134:4751:6769 | rank: 512]

It can ping its neighbour:

2020-12-10 16:26:09,024 #  ping fe80::bcf1:5134:4751:6769
2020-12-10 16:26:09,089 # 12 bytes from fe80::bcf1:5134:4751:6769%5: icmp_seq=0 ttl=64 rssi=-77 dBm time=57.478 ms

But the BR can’t ping it :frowning: it is so wierd! Has anyone seen this behavour before? I notice the RSSI are all quite low - but… ping is lossless from BR to node1 and from node2 to node1 Thanks!

#2

Hey Kirk, just a small check beforehand: In your example, you use the link-local IPv6 address when pinging (fe80:…). Did you also used the link-local address when you pinged the farthest node from the BR? In a multihop network, you have to use the global IPv6 address (2001:…) of your node. Maybe you are already doing this, just wanted to be sure before we continue debugging (:

#3

I only used LL addresses from node2 as I knew that would hit node1 OK. From BR I have all their v6 2001 addresses in /etc/hosts to avoid confusion :wink:

#4

Hi Kirk! I fixed the formatting of your post to make it better readable. Namely, I made each pasted terminal output a

codeblock
#5

Thanks! I had just got back from a dark forest wearing wellington boots - so could not be bothered to fix it :wink:

1 Like
#6

I think having an output of nib route for the middle node (node1?) would be also be helpful. Does it contain a correct routing entry to node2? And does pinging using the global address from node1<->node2 also work?

#7

true! I can do that in the morning (I am now an expert at putting riot nodes 3m up a tree with a pole!). We have a poster about all this tomorrow evening - so you could say I am like a typical last-minute student but the problem has been known for weeks sadly. See: https://mountainsensing.org/deployment/new-forest-test-bed/ for the poster and a photo of the hardware.

#8

I know, the SAMR30 has a different (but similar) radio, but could this be related to the problem described in #11256?

#9

I tried to reply by email. It hasn’t shown up yet. Please clarify: two notes + BR? Or is BR one of the two?

#10

I like it how you hid the RIOT node with a couple of leaves on the ground. Very nice camouflage skills :smile:

What usually also helps in these scenarios is a separate sniffer node to record the RPL and ND traffic (if you have a separate hardware for that?)

1 Like
#11

Oh, that’s it. you have the hidden node problem. https://en.wikipedia.org/wiki/Hidden_node_problem :slight_smile: :innocent:

#12

yes two nodes and one BR. And yes a sniffer would be good! we used one for our previous contiki work :wink: is there one in the git repo?

Someone stole Node3 :frowning: a few weeks ago

#13

There is a sniffer application here. I’d probably go with a RasPI using an openlabs and tshark, though.

Is it possible to have a testing setup at home? You could put the correct hardware addresses on an ignore list for the BR and node2 using the l2filter module. See http://doc.riot-os.org/l2filter_8h.html . If you enable the module, then you should get some shell commands. You can also filter the addresses programmatically, like here https://github.com/RIOT-OS/RIOT/blob/master/sys/shell/commands/sc_gnrc_netif.c#L1399

#14

Does the openlabs work with Sub-GHz 802.15.4? The sniffer application should be able to work though.

#15

Thanks!

#16

it tested at home OK which is why I suspect there may be an issue with low RSSI links…? but even at home I reduced the TXPOWER a lot so they were -80db away

#17

I’m wondering: can node 3 also (sometimes) see node 1? The current RPL implementation will always prefer the shortest route, so even if the link is really bad, it will be taken instead of going an additional hop.

#18

I left the BR pinging node2 for a few hours and didn’t see a reply… but that was its 2001 addr. Hmm I can easily move node2 further away (much easier than messing with TXPOWER as that can make an assymetry where they can RX but can’t reply).

#19

latest this morning! with :52 as node1 up a tree and 5a6e nearby on the ground out of reach of BR.

node1 said route was stale:

> 2020-12-11 14:05:59,744 #  nib neigh
2020-12-11 14:05:59,747 # fe80::ec26:3905:43b7:5a6e dev #5 lladdr EE:26:39:05:43:B7:5A:6E router STALE GC
But can ping node2:
2020-12-11 14:08:44,698 #  ping fe80::ec26:3905:43b7:5a6e
2020-12-11 14:08:44,763 # 12 bytes from fe80::ec26:3905:43b7:5a6e%5: icmp_seq=0 ttl=64 rssi=-71 dBm time=65.395 ms

Border router says:

2020-12-11 14:38:54,040 # nib route
2020-12-11 14:38:54,044 # 2001:fdfd::/64 dev #6
2020-12-11 14:38:54,057 # 2001:fdfd::5c1d:e070:a4e1:52/128 via fe80::5c1d:e070:a4e1:52 dev #6
2020-12-11 14:38:54,068 # 2001:fdfd::ec26:3905:43b7:5a6e/128 via fe80::5c1d:e070:a4e1:52 dev #6
2020-12-11 14:38:54,078 # 2001:fdfd::bcf1:5134:4751:6769/128 via fe80::5c1d:e070:a4e1:52 dev #6
2020-12-11 14:38:54,088 # 2001:fdfd::58a4:8450:8511:6445/128 via fe80::bcf1:5134:4751:6769 dev #6

one of which is a node that’s now off (5769). But it seems to see a route across to 52 but sadly can’t ping it

2020-12-11 14:42:44,003 # ping  2001:fdfd::ec26:3905:43b7:5a6e
2020-12-11 14:42:47,011 #
2020-12-11 14:42:47,020 # --- 2001:fdfd::ec26:3905:43b7:5a6e PING statistics ---
2020-12-11 14:42:47,030 # 3 packets transmitted, 0 packets received, 100% packet loss

Time for a lot more lab testing I think!

#20

Again edited for better readability :wink: