openthread: Leader holds onto phantom routing entries in netdata for router that has disappeared in some cases leading to routing problems on mesh

Updated description:

OK, so update, we’ve traced this to a phantom routing entry in the netdata from 0x9800. This does not exist in the leader neighbor table, the routing table, or in nexthop data, so its unclear how it got into this state. Rebooting the leader also does not clear the phantom entry, which is at least 1 area of possible improvement/mitigation. @abtink will look further into next steps.

leader was 0x5000, a BR at commit 34ecac8536f6a8e23391b7f25b7ec401bf1ae305

Original description:

Describe the bug A clear and concise description of what the bug is. Off mesh routing for children does not work in some cases

To Reproduce Information to reproduce the behavior, including: Unclear. Using an MG21 based FTD, off mesh pings are unable to return from child device. Pings from same address to parent OMR IPv6 address work as expected.

message me directly for networkkey if you need, here’s snippet:

from pcap:

5873	Sep 11, 2023 09:16:37.905825000 EDT	575.076170	fda8:29b7:197d:1:18ff:de02:8708:7ee1	::65da:8596:83ac:b473	ICMPv6	75	Echo (ping) request id=0xec87, seq=15, hop limit=63 (reply in 5875)	
5875	Sep 11, 2023 09:16:37.923126000 EDT	575.093471	::65da:8596:83ac:b473	fda8:29b7:197d:1:18ff:de02:8708:7ee1	ICMPv6	71	Echo (ping) reply id=0xec87, seq=15, hop limit=64 (request in 5873)	
5877	Sep 11, 2023 09:16:37.929036000 EDT	575.099381	fd00:db8::ff:fe00:e800	fd00:db8::ff:fe00:e816	ICMPv6	72	Destination Unreachable (no route to destination)	
Screenshot 2023-09-11 at 10 01 54 AM image

From other BR node:

> netdata show
Prefixes:
fd2f:2067:77a8:1::/64 paros low 5000
Routes:
::/0 s med 9800
::/0 s med cc00
::/0 s med 5000
::/0 s med 8400
Services:
44970 5d fdcf8d62857000009576444e75689eb4d120 s cc00
44970 5d fdcf8d628570000079306d87f36d3acbd128 s 5000
Contexts:
fd2f:2067:77a8:1::/64 1 c
Done
  1. Git commit id 7f3013cb0
  2. IEEE 802.15.4 hardware platform mg21
  3. Build steps
  4. Network topology ~20 thread devices

Expected behavior A clear and concise description of what you expected to happen.

Console/log output If applicable, add console/log output to help explain your problem.

Additional context Add any other context about the problem here. ota cap child no routing.pcapng.zip

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Comments: 26 (19 by maintainers)

Most upvoted comments

@wimleers the latest which is 3.6.136

Join the discord, all the chat is happening there and in the last month nanoleaf has committed some resource in there and they are active with us. The pinned notes will have a link and password to the beta info with list of current identified issues being worked on and a daily survey you can do to say how stable etc things have been.

In case you saw something different this is how to get the beta firmware

https://helpdesk.nanoleaf.me/en-US/how-do-i-sign-up-for-beta-software-updates-for-my-nanoleaf-lights-341522

Fyi I have 24x gu10’s and on this firmware they are largely available with I would say On average 3 having connections issues sporadically over a 24hr period

Another thing I noticed is the destination of ping is shown as fda8:29b7:197d:1:18ff:de02:8708:7ee1 which seems to be mesh-lcoal address. The OMR prefix is fd2f:2067:77a8:1::?

I think fda8:29b7:197d:1::/64 is the AIL on-link prefix and fd2f:2067:77a8:1:: is the Thread on-mesh prefix.