TIMMERFLOTTE angelernt, -infra wieder deaktiviert

Der Workaround aus TP12.1 ist durchgespielt: dirtyvader-infra temporaer auf
ap2, iPhone auf VLAN20, TIMMERFLOTTE per Companion-App angelernt (25,44 C /
53,1 % rF / Batterie 100 %, Technik UG). SSID danach wieder vom Funk;
cfg-infra/dp-infra/sec-infra bleiben auf User-Wunsch inaktiv am Manager
stehen, damit das naechste Thread-Geraet ein Zweizeiler ist. Beide Akten
geschlossen, crs326-core transaktionsfrei.

TP12.1 bleibt offen: der Workaround umgeht das fehlende IPv6-Routing, er
behebt es nicht.

Neuer Gotcha in CLAUDE.md, an dem ich mich heute selbst verrannt habe:
slave-configurations zu setzen bewirkt am Funk nichts ohne
remote-cap provision -- und zwar in BEIDE Richtungen, auch beim Entfernen.
Schlimmer: beim Rueckbau wird der Interface-Kommentar geleert, waehrend der
VAP weitersendet. Ich habe auf comment~"dirtyvader-infra" geprueft, nichts
gefunden und "weg" gemeldet -- tatsaechlich liefen wifi13/wifi18 mit vlan=20
weiter. Richtige Abnahme ist datapath.vlan-id am CAP. Also wieder: Wirkung
messen, nicht Anzeige.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -74,6 +74,16 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
 - **Beide APs = CAPs, Manager ist `crs326-core` (TP28 ✅ 2026-08-17).** Der Entscheid „kein CAPsMAN" von 2026-07-22 ist **revidiert**: er galt der Konstellation ap1=Manager+AP, in der ein Manager seine eigenen Radios nicht provisionieren kann — mit dem Core als Manager sind beide APs symmetrisch. Der Core braucht dafür **kein** `wifi-qcom`, `capsman` steckt im Basispaket.
   - 🔴 **Messfalle: unter CAPsMAN führt der MANAGER die Tabellen.** `/interface/wifi/registration-table` und die `wireless`-Logs sind auf ap1/ap2 **leer**, obwohl das WLAN läuft. **Immer am Manager zählen.**
   - 🔴 **Die CAPs finden den Manager per Layer-2-Discovery** (`discovery-interfaces=vlan99`, `current-caps-man-address` ist eine **MAC**, keine IP). Deshalb müssen **MNDP (udp/5678)** und **CAPWAP (udp/5246-5247)** in der `input`-Kette des Core erlaubt bleiben — sonst kommt das WLAN nach dem nächsten AP-Reboot nicht zurück, während laufende Sessions unauffällig weiterlaufen (Fund 2026-08-18, TP5 Etappe 4).
+  - 🔁 **Slave-VAPs aendern heisst zweimal arbeiten (2026-08-22).** `slave-configurations` in einer
+    `provisioning`-Zeile zu setzen bewirkt am Funk **nichts**, solange nicht
+    `/interface wifi capsman remote-cap provision [find where identity="apX"]` nachgezogen wird —
+    und das gilt in **beide** Richtungen: auch beim Entfernen senden die VAPs sonst munter weiter.
+    🔴 **Und die Abnahme nicht am Kommentar festmachen:** beim Rueckbau wird der Interface-Kommentar
+    geleert, waehrend der VAP steht. Wer auf `comment~"ssid"` prueft, sieht "weg" und liegt falsch.
+    Richtig ist `datapath.vlan-id` bzw. die Interface-Zahl **am CAP** (`/interface wifi print` dort).
+    Beim Interface-*Zustand* ist ueberhaupt der CAP die Wahrheit: der Manager zeigt nach einer
+    Re-Provisionierung `running=false` fuer alle `cap-*`, waehrend am CAP alles laeuft — das
+    Gegenstueck zur Regel, dass die *Registration-Table* am Manager zu lesen ist.
   - **Local Forwarding ist keine Einstellung mehr:** im neuen `/interface/wifi` gibt es kein zentrales Forwarding, `datapath` existiert dort nicht.
   - 🔴🔴 **`/interface wifi cap slaves-datapath` MUSS auf beiden APs gesetzt sein** (`dp-caps-slaves`, ein lokales datapath-Objekt mit `bridge=bridge` und **ohne** `vlan-id`). Es ist das Einzige, was die vom Manager erzeugten **Slave-VAPs** lokal in die Bridge haengt: der Manager schickt `datapath.bridge=bridge` mit, **der CAP uebernimmt davon nur die `vlan-id`**. Fehlt es, assoziieren Clients auf `-iot`/`-media`/`-untrusted`/`-guest` sauber und bekommen **nie DHCP**, waehrend `dirtyvader-main` weiterlaeuft — dessen Master-Radios `wifi1`/`wifi2` sind statische Bridge-Ports. Genau so lagen IOT+MEDIA am 2026-08-18 rund 14 Stunden (Ursache: CAPsMAN-Cutover 08-17, nicht die TP5-Haertung). **Abnahme fuer jeden WLAN-Umbau ist eine frische DHCP-Lease pro SSID — NICHT die Registration-Table**, die zeigte waehrend des Ausfalls 25 zufriedene IOT-Clients.
   - 🔎 **Merkregel „connect ok, kein DHCP":** zuerst `torch` auf dem betroffenen VLAN am Core UND den TP5-Drop-Log lesen. Sind **beide leer**, wird nichts verworfen — es kommt nichts an, und die Firewall ist entlastet. Dann liegt es an L2 (Bridge-Mitgliedschaft/Tagging), nicht am Regelwerk.

docs/teilprojekte.md

@@ -646,6 +646,14 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   beides aus. `cfg-infra` / SSID `dirtyvader-infra` (`dp-infra`, VLAN20, `sec-infra` mit PSK) existiert am
   Manager **bereits**, ist nur in **keiner** `provisioning`-Zeile als Slave hinterlegt. Runbook:
   [`docs/matter-pairing-infra-ssid-runbook.md`](matter-pairing-infra-ssid-runbook.md).
+- ✅ **2026-08-22 durchgefuehrt und wieder zurueckgebaut.** `dirtyvader-infra` temporaer auf ap2
+  (Transaktion `TEST-infra-ssid-matter-pairing`, Scope `wifi-provisioning`), iPhone dort hinein,
+  **TIMMERFLOTTE per Companion-App angelernt** — liefert 25,44 °C / 53,1 % rF / Batterie 100 %
+  (Bereich Technik UG). Danach SSID deaktiviert; `cfg-infra`/`dp-infra`/`sec-infra` bleiben auf
+  User-Wunsch **inaktiv am Manager stehen**, damit der Weg beim naechsten Thread-Geraet ein
+  Zweizeiler ist. Beide Akten geschlossen, `crs326-core` transaktionsfrei.
+  ⇒ **Der Workaround ist damit bewiesen** — und TP12.1 bleibt trotzdem offen: er umgeht das
+  fehlende IPv6-Routing, er behebt es nicht.
 - ✅ **Der Weg, der das Problem dauerhaft erledigt:** Matter-Server-Option **`ble_proxy: true`** (ab HA
   2026.06, hier 2026.8.3). Dann kommissioniert **HA selbst** über seinen Bluetooth-Stack; das Telefon ist
   raus und die VLAN-Grenze wird nie berührt. Braucht eine **connectable** BLE-Quelle — Shelly-Proxies sind

docs/transaktionen/TEST-infra-ssid-matter-pairing.json

@@ -8,7 +8,8 @@
   "reason": "dirtyvader-infra temporaer auf ap2: iPhone fuer Matter-Commissioning auf VLAN20 (TP12.1)",
   "started": "2026-08-22",
   "expires": "2026-08-29",
-  "state": "open",
+  "state": "rolledback",
   "snapshot": "docs/transaktionen/TEST-infra-ssid-matter-pairing.snapshot.rsc",
-  "device_backup": ""
+  "device_backup": "",
+  "closed": "2026-08-22"
 }

docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback-deployed.rsc

@@ -0,0 +1,6 @@
+# TATSAECHLICH DEPLOYT am 2026-08-22 (Plan 1469f0f7-fc52-47e1-bd65-a83ac709d89c, Completed).
+# Danach ZWINGEND: /interface wifi capsman remote-cap provision [find where identity="ap2"]
+# Ohne die Re-Provisionierung bleiben die VAPs am CAP bestehen und senden weiter.
+# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
+/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
+/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest

docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc

@@ -1,3 +1,18 @@
-# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
-/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
-/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
+# Rueckbau-VORSCHLAG fuer TEST-infra-ssid-matter-pairing (crs326-core, Scope wifi-provisioning)
+# Aus dem Snapshot vom 2026-08-22. NICHT ungeprueft deployen:
+# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
+# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
+
+/interface wifi provisioning
+add action=create-dynamic-enabled comment="ap1 5GHz" master-configuration=\
+cfg-main-5g-ap1 radio-mac=D0:EA:11:4D:40:E5 slave-configurations=\
+cfg-media,cfg-untrusted,cfg-guest
+add action=create-dynamic-enabled comment="ap1 2.4GHz" master-configuration=\
+cfg-main-2g-ap1 radio-mac=D0:EA:11:4D:40:E6 slave-configurations=\
+cfg-iot,cfg-media,cfg-untrusted,cfg-guest
+add action=create-dynamic-enabled comment="ap2 5GHz" master-configuration=\
+cfg-main-5g-ap2 radio-mac=D0:EA:11:4D:40:3E slave-configurations=\
+cfg-media,cfg-untrusted,cfg-guest
+add action=create-dynamic-enabled comment="ap2 2.4GHz" master-configuration=\
+cfg-main-2g-ap2 radio-mac=D0:EA:11:4D:40:3F slave-configurations=\
+cfg-iot,cfg-media,cfg-untrusted,cfg-guest