Router table: Why is Extended MAC zero?

[olavt]

This is a command from the OTBR:

$ sudo ot-ctl router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC | Link |
+----+--------+----------+-----------+-------+--------+-----+------------------+------+
| 37 | 0x9400 | 63 | 0 | 3 | 3 | 11 | 5a6edbbc88aad86c | 1 |
| 51 | 0xcc00 | 37 | 1 | 0 | 0 | 59 | f68cb5fab39b3e14 | 0 |
| 61 | 0xf400 | 63 | 0 | 0 | 0 | 0 | 0000000000000000 | 0 |

Why is the Extended MAC for RLOC16=0xf400 zero?

If I look at the Matter Thread Diagnostic cluster for a Matter over Thread device, I can see that the ExtAddress for RLOC16=0xf400 is 2F7F772DD562B40. However the ExtAddress for RLOC16=CC00 is now zero (which in the router table above is f68cb5fab39b3e14).

Why does the router tables contain entries with zero for the ExtAddress?

[jwhui]

The router table contains entries for all active routers in the Thread partition. A router will only learn the Extended MAC Address of neighboring routers. A router will not learn the Extended MAC for routers that are multiple hops away.

[olavt]

In the example above the entry with ExtAddress equal to zero is the Open Thread Border Router node on which I issued the " ot-ctl router table" command. Why shouldn't it know it's own Extended MAC address? The OTBR node also know the Extended MAC address for Matter NodeId 7, which is furthest away from the OTBR.

[jwhui]

The Extended MAC Address field is only populated when establishing a neighbor link. A router does not establish a neighbor link with itself, so the Extended MAC Address field is never populated.

[abtink]

Because it does not establish a link with itself. 😃

The last column, "Link," indicates the neighboring router with which the device has a link. The router table provides information from the router table, which tracks all allocated routers from the "Router ID mask" and any neighboring routers with which the device has established a link.

Other APIs are available to get the device's extended address; using the router table for this is unnecessary (and incorrect).

To learn information (e.g., diagnostic information) from other nodes within the mesh (even those multiple hops away), you can use the meshdiag commands, for example, meshdiag topology.

[olavt]

What is the ver:x output and why is it missing for Id:51?

$ sudo ot-ctl meshdiag topology
id:61 rloc16:0xf400 ext-addr:02f7f772dd562b40 ver:5 - me - leader - br
3-links:{ 37 }
id:37 rloc16:0x9400 ext-addr:5a6edbbc88aad86c ver:4
3-links:{ 51 61 }
id:51 rloc16:0xcc00 ext-addr:f68cb5fab39b3e14
3-links:{ 37 }

And why does the output say "3-links:{ 37 }" when it looks like there is only 1 link (to 37)?

[jwhui]

"ver:x" refers to the Thread Version if known. When it is missing, the Thread Version is not known for the given node.

"3-links" refers to the set of Router IDs to which this router has a incoming link with link quality 3.

See documentation for more detail.

[olavt]

Could you elaborate a bit more on the Thread versioning?

The Thread 1.4 specification was released quite recently. But ver:5 means Thread version 5.

I find this a bit confusing.

[jwhui]

Thread 1.4.0 Section 4.4.17 defines the mapping to TLV encoding - Thread 1.4.0 corresponds to Version TLV value 5.

You can also find the mapping here:

openthread/include/openthread/thread.h

Lines 55 to 60 in 54f6c27

	#define OT_THREAD_VERSION_INVALID 0 ///< Invalid Thread version
	#define OT_THREAD_VERSION_1_1 2 ///< Thread Version 1.1
	#define OT_THREAD_VERSION_1_2 3 ///< Thread Version 1.2
	#define OT_THREAD_VERSION_1_3 4 ///< Thread Version 1.3
	#define OT_THREAD_VERSION_1_3_1 5 ///< Thread Version 1.3.1 (alias for 1.4)
	#define OT_THREAD_VERSION_1_4 5 ///< Thread Version 1.4