otbr is meant to be an additive co-border-router on the existing Nest Thread
network (it's seeded with the Nest dataset to join the same partition). In
practice it does not merge cleanly: its SLZB-06 radio is RF-isolated enough
that otbr elects itself leader of a rival partition, and the network churns
(OMR prefix observed changing fd5f -> fdd5, leader role flapping). The two
same-network partitions then bridge only over the Ethernet backbone, which
carries a ping but is too slow for the large fragmented Matter CASE handshake:
every device stays mDNS-discoverable while CASE times out. Scaling otbr to 0
re-merges the mesh onto the Nest hubs and Matter recovers.
Explicitly NOT a root-cause of a config bug. The DHCP/sbr routing changes
(19a4482, df61407) were suspected and investigated: matter-server's IPv6 path
to the mesh works (reaches devices, ping ok), sbr's v6 table 100 is an inert
orphan (no v6 rule references it), and otbr's eth0 IPv6 default is outranked by
net1's pref-high RA default. The instability sits at the Thread partition
layer, not in the pod's routing table. Re-enable only after the co-BR
integration is verified to MERGE (one partition, one OMR, otbr's router table
shows the Nest routers) rather than split.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
k.rennerandClaude Opus 4.8