From 723ec6a30b63e7c398e74bf64fa57ae05de708cf Mon Sep 17 00:00:00 2001 From: Konstantin Renner Date: Sat, 11 Jul 2026 03:28:26 +0200 Subject: [PATCH] =?UTF-8?q?otbr:=20disable=20(replicas=200)=20=E2=80=94=20?= =?UTF-8?q?it=20splits=20the=20Nest=20Thread=20partition=20and=20breaks=20?= =?UTF-8?q?Matter?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- kubernetes/apps/otbr/deployment.yaml | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/kubernetes/apps/otbr/deployment.yaml b/kubernetes/apps/otbr/deployment.yaml index 2ebf0b84..7b867ba2 100644 --- a/kubernetes/apps/otbr/deployment.yaml +++ b/kubernetes/apps/otbr/deployment.yaml @@ -5,7 +5,26 @@ metadata: labels: app.kubernetes.io/name: otbr spec: - replicas: 1 + # Disabled 2026-07-11 (replicas: 0) after otbr broke Matter. + # + # otbr is seeded with the Nest network's dataset so it should join the + # existing partition as an additive co-BR. In practice it does not merge + # cleanly: its SLZB-06 radio is RF-isolated enough from the Nest mesh that + # otbr elects itself leader of a rival partition (or the network re-addresses + # under a new OMR prefix, observed fd5f -> fdd5). The two same-network + # partitions then bridge only over the Ethernet backbone, which carries a + # ping but is too slow for the large fragmented CASE handshake -- every + # Matter device stays mDNS-discoverable while CASE times out. Removing otbr + # re-merges the mesh onto the Nest hubs and Matter recovers. + # + # This is NOT a diagnosis of a specific config bug: the DHCP/sbr routing + # changes (19a4482, df61407) were investigated and matter-server's IPv6 path + # to the mesh works (reaches devices, ping ok); sbr's v6 table 100 is an + # inert orphan and 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. + replicas: 0 strategy: type: Recreate selector: -- 2.54.0