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
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 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!
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 (:
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?
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.
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
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.
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).
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