otbr: disable (replicas 0) — splits the Nest Thread partition, breaks Matter #151

Merged
k.renner merged 1 commits from fix/otbr-disable-splits-thread into master 2026-07-11 01:30:17 +00:00
Owner

Turns off otbr (scale to 0 in git) to stop it breaking Matter, replacing tonight's live scale-0 + suspended-Kustomization hotfix with a clean GitOps state.

otbr forms a rival Thread partition (its SLZB-06 radio is RF-isolated from the Nest mesh; OMR churned fd5f->fdd5, leader role flapped); the two same-network partitions bridge only over the Ethernet backbone, too slow for the large fragmented Matter CASE handshake, so devices stay mDNS-discoverable while CASE times out. Removing otbr re-merges the mesh onto the Nest hubs and Matter recovers.

NOT a root-cause of a config bug: the DHCP/sbr changes (19a4482, df61407) were investigated -- matter-server's IPv6 path to the mesh works, sbr's v6 table 100 is an inert orphan, otbr's eth0 default is outranked by net1's pref-high RA default. The instability is at the Thread partition layer.

Re-enable only after the co-BR integration is verified to MERGE (one partition, one OMR, otbr's router table shows the Nest routers) instead of split.

After merge: resume the otbr Flux Kustomization (currently suspended) so Flux enforces replicas:0.

Turns off otbr (scale to 0 in git) to stop it breaking Matter, replacing tonight's live scale-0 + suspended-Kustomization hotfix with a clean GitOps state. otbr forms a rival Thread partition (its SLZB-06 radio is RF-isolated from the Nest mesh; OMR churned fd5f->fdd5, leader role flapped); the two same-network partitions bridge only over the Ethernet backbone, too slow for the large fragmented Matter CASE handshake, so devices stay mDNS-discoverable while CASE times out. Removing otbr re-merges the mesh onto the Nest hubs and Matter recovers. NOT a root-cause of a config bug: the DHCP/sbr changes (19a4482, df61407) were investigated -- matter-server's IPv6 path to the mesh works, sbr's v6 table 100 is an inert orphan, otbr's eth0 default is outranked by net1's pref-high RA default. The instability is at the Thread partition layer. Re-enable only after the co-BR integration is verified to MERGE (one partition, one OMR, otbr's router table shows the Nest routers) instead of split. After merge: resume the otbr Flux Kustomization (currently suspended) so Flux enforces replicas:0.
k.renner added 1 commit 2026-07-11 01:29:46 +00:00
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.renner merged commit ea4cb567f4 into master 2026-07-11 01:30:17 +00:00
Sign in to join this conversation.