OpenThread devices disappearing from analytics

[dakhnod]

Using the openthread posix border router, I have 6 devices connected to one network.
Polling http://localhost:8081/diagnostics every few seconds, I am noticing that some of my devices are not present in the list quite often.

The graph presented by otbr-web also looks different every few seconds, which seems to use the same data source.

My questions are:

1. How does my otbr instance know of all devices in its network?
2. Can I somehow sniff disconnection/reconnections events myself?
3. What could be the reason for my devices constantly reconnecting?

Thanks for your time!

[wgtdkp]

OTBR sends multicast queries to collect information from all devices and wait for a few seconds before returning and rendering the UI. So it can happen that your device doesn't receive the query or the response is dropped after timeout.

The OpenThread network diagnostics API is used to implement this functionality, you can use the CLI to see what is happening in the backend: https://github.com/openthread/openthread/blob/main/src/cli/README.md#networkdiagnostic-get-addr-type-

[dakhnod]

Thanks! When I run

ot-ctl networkdiagnostic get ff02::1 0 23

Some devices report both TLVs, some only report the ExtAddr, not the EUI64.

A assume that this is what causes some devices to disappear in the graphical topology overview.

What could be the reason for the devices to not report their EUI64?

[jwhui]

EUI-64 TLV was implemented about 10 months ago (see openthread/openthread#9795). Do yo have some devices running an older version of OpenThread?

[dakhnod]

My otbr-agent reports version 0.3.0.

In any case, running ot-ctl networkdiagnostic get ff02::1 0 pings all devices far more reliably than reloading the tpopology graph.
What could be the reason for this?

[jwhui]

I was specifically referring to your comment:

Some devices report both TLVs, some only report the ExtAddr, not the EUI64.

Whether a device responds to EUI-64 TLV or not is dependent on the functionality of that device. Do you have a mix of devices running different versions of OpenThread?

[dakhnod]

@jwhui sorry for the miscommunication.

The one device I checked runs otbr version 0.3.0, and doesn't report the EUI64

[jwhui]

The one device I checked runs otbr version 0.3.0, and doesn't report the EUI64

Are you able to indicate which git commit?

[dakhnod]

We are using thread-reference-20230710. Probably the TLV is not present yet, there...

[dakhnod]

Another question: my query response looks like this: DIAG_GET.rsp/ans from fe80:0:0:0:d856:ecd5:376f:19aa:.
To me, this looks like a LL-address. But, if I recall correctly, LL-addresses only reach for a single hop.
Does that mean I cannot get diagnostic data from nodes that are more than one hop away?
Even if the query reaches all devices via ff02::1, is their answer able to reach me more than one hop away?

[jwhui]

In Thread, link-local scope is limited to those neighbors that are within direct radio range.

[dakhnod]

Right, so I can only get diagnostics data from those devices?

[jwhui]

Right, so I can only get diagnostics data from those devices?

When using link-local addresses, you are limited to direct radio range. If you want to communicate with devices that may be multiple hops away, then use non-link-local addresses.

[dakhnod]

Yes, but the CLI does only use LL addresses, right?

[jwhui]

You can use mesh-local addresses too:

https://github.com/openthread/openthread/blob/main/src/cli/README.md#networkdiagnostic-get-addr-type-