TP25: ap3-FT-Drift behoben + Kanalplan committed (140/140)

ap3 trug auf wifi1/wifi2 einen Werks-Inline security.ft=yes (Bring-up-Skript
tp28-ap3-phase2-cap.rsc unset !ft-over-ds, aber nicht !ft; Abnahme zaehlt nur
benannte security-Objekte -> Inline-Wert unsichtbar). Gemischtes FT-ESS =
Strong-Signal-Abbrueche (-43/-45 dBm) NUR auf ap3 bei 3/3 Strichen. Live per
!security.ft geradegezogen (uniform ft=no), Bring-up-Quelle korrigiert.

Kanalplan committed: Template auf DFS-Frequenzlisten (ch-5g-ap1=5260,5280,
ch-5g-ap2=5300,5320) + ap1-Provisioning-Zeilen (radio-mac ...E5/...E6) wieder
aufgenommen. Push nach bf-golden-config + GitRepo-Sync + refresh-compliance ->
140/140, 0 Drifts; Transaktion TP25-kanalplan-ap1-live committed.

Doku: Ist-Stand, Fund-E-Block, CLAUDE.md Punkt 5 (Merkregel: nach jeder
sec-main-FT-Aenderung jeden CAP einzeln auf security.ft pruefen).

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

CLAUDE.md

@@ -20,6 +20,13 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
    am 09-01 zurueckgebaut; Hebel 2–4 entfallen, **kein Geraete-Write** (Soll stand: `ft=yes ft-over-ds=yes`,
    **Compliance 140/140**). **Am 2026-09-04 hat Christoph `ft=no` auf `sec-main` als Dauerzustand
    entschieden** (Hebel 2 doch gezogen: Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen).
+   🔴 **Nachtrag 09-04: `ft=no` war NICHT uniform.** ap3 trug einen Werks-Inline `security.ft=yes` auf
+   `wifi1/wifi2` (Bring-up unset `!ft-over-ds`, aber nicht `!ft`; Abnahme zählt nur benannte
+   security-Objekte → Inline-Wert unsichtbar). Gemischtes FT-ESS → Strong-Signal-Abbrüche (−43/−45 dBm)
+   **nur auf ap3** bei 3/3 Strichen. Fix: `!security.ft` auf ap3 (uniform `ft=no`), Quelle
+   `tp28-ap3-phase2-cap.rsc` korrigiert. **Merkregel: nach jeder `sec-main`-FT-Änderung jeden CAP einzeln
+   `get wifiN security.ft` prüfen — CAP-lokale Inline-Overrides sind compliance-unsichtbar.**
+   Der TP25-Kanalplan ist am 09-04 committed (DFS-Frequenzlisten + ap1-Provisioning, **140/140, 0 Drifts**).
    Offen in TP25 bleibt nur **ap2 unterperformt** (2 m/−80 dBm). Vorstufen:
    [Befund](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md) ·
    [Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md) ·

docs/teilprojekte.md

@@ -28,10 +28,13 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` ·
 ## Ist-Stand (Kurz)
 
 **Stand 2026-09-04 — live gegen die Geräte geprüft (MikroMCP/REST/SSH), nicht aus der Doku abgeschrieben.**
-**Compliance 138/140** — 2 Drifts, beide aus der Kanalplan-Arbeit: `wifi-channel` (offene Transaktion
+**Compliance 140/140, 0 Drifts** (2026-09-04 nachmittags). Der TP25-Kanalplan ist **committed**:
-`TP25-kanalplan-ap1-live`, im Scope) + `wifi-provisioning` (ap1-Provisioning-Regeln, **AUSSERHALB** des
+Template auf DFS-Frequenz-Listen umgestellt (`ch-5g-ap1=5260,5280`, `ch-5g-ap2=5300,5320`) + die
-Transaktions-Scopes — Side-Effect des ap1-Reaktivierens). `wifi-security` gruen seit 2026-09-04 (`ft=no`
+ap1-Provisioning-Zeilen wieder aufgenommen → Transaktion `TP25-kanalplan-ap1-live` geschlossen und der
-auf `sec-main`, s. unten).
+`wifi-provisioning`-Drift weg. `wifi-security` gruen (`ft=no` auf `sec-main`).
+🔴 **Zusätzlich live behoben (nicht compliance-sichtbar):** ap3 trug auf `wifi1/wifi2` einen Werks-Inline
+`security.ft=yes` — gemischtes FT-ESS, das die 3/3-Strich-Abbrüche vom 09-04 erklärt. Unset → uniform
+`ft=no` on-air; Bring-up-Quelle `tp28-ap3-phase2-cap.rsc` um `!security.ft` ergänzt (s. Fund-E-Block).
 *(Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt. Wer diesen Block
 liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 - ✅ **TP25 Multi-Pin-Konsole (2026-09-04):** die Klick-Konsole (`docs/tp6-marker/server.py`) ist auf
@@ -46,7 +49,14 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   1d18h, `caps joined=0` → keine Reboot-Artefakte). ⇒ **7.24.1 (TP27) war die Ursache/der Fix, nicht
   `ft-over-ds`.** Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen, **kein Geräte-Write**. **Am
   2026-09-04 hat Christoph `ft=no` auf `sec-main` als Dauerzustand entschieden** (Hebel 2 doch gezogen,
-  Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen). Offen in
+  Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen). 🔴 **Nachtrag 2026-09-04:** „ohne FT"
+  galt bis dahin **nur für Manager/ap1/ap2** — **ap3** trug einen Werks-Inline `security.ft=yes` auf
+  `wifi1/wifi2` (Bring-up-Skript unset `!ft-over-ds`, aber nicht `!ft`; die Abnahme zählt nur benannte
+  security-Objekte und sah den Inline-Wert nicht). Das ist ein **gemischtes FT-ESS** und erklärt den
+  Abbruch bei 3/3 Strichen: Log zeigte wiederkehrende Strong-Signal-Disconnects (−43/−45 dBm) **nur auf
+  ap3** (`cap-wifi2/4`, `dirtyvader-main`). Fix: `!security.ft` auf ap3 → uniform `ft=no`; Quelle
+  korrigiert. **Merkregel: nach jeder `sec-main`-FT-Änderung jeden CAP einzeln auf `security.ft` prüfen —
+  CAP-lokale Inline-Overrides sind compliance-unsichtbar.** Offen in
   TP25 bleibt nur der separate Punkt **ap2 unterperformt** (2 m/−80 dBm). Handoff:
   [`docs/handoff-20260902-tp25-fund-e-messung.md`](handoff-20260902-tp25-fund-e-messung.md).
 - ⏸️ **TP41 CF-Access-Reparatur — ZURÜCKGESTELLT 2026-09-01 (User-Entscheid; Rest wartet auf Info):** Session 720h,

nautobot/mikrotik_routeros.j2

@@ -203,8 +203,11 @@
 #      Literal-Block wie die L2-Fabric: Radio-MACs und Kanalzuordnung sind
 #      geraetegebunden und in Nautobot nicht modelliert. Aenderungen daran sind
 #      bewusst sichtbare Template-Aenderungen.
-/interface wifi channel add band=5ghz-ax frequency=5180 name=ch-5g-ap1 width=20/40mhz
+# ap1/ap2 auf Band B (DFS) seit dem TP25-Kanalplan-Umzug (committed 2026-09-04). Frequenz-LISTE
-/interface wifi channel add band=5ghz-ax frequency=5220 name=ch-5g-ap2 width=20/40mhz
+# statt Einzelwert: bei einer Radar-Erkennung muss das Radio auf einen anderen Wert der Liste
+# ausweichen koennen -- ein Einzelwert waere ein SPOF. ap1=52+56 (5260/Ce), ap2=60+64 (5300/Ce).
+/interface wifi channel add band=5ghz-ax frequency=5260,5280 name=ch-5g-ap1 width=20/40mhz
+/interface wifi channel add band=5ghz-ax frequency=5300,5320 name=ch-5g-ap2 width=20/40mhz
 /interface wifi channel add band=2ghz-ax frequency=2412 name=ch-2g-ap1 width=20mhz
 /interface wifi channel add band=2ghz-ax frequency=2462 name=ch-2g-ap2 width=20mhz
 # ap3 (cAP ax, Technik UG) seit 2026-08-30. Kanaele aus dem TP25-Plan vom 2026-08-24:
@@ -244,18 +247,16 @@
 /interface wifi configuration add channel=ch-2g-ap3 country=Austria datapath=dp-main mode=ap name=cfg-main-2g-ap3 security=sec-main ssid=dirtyvader-main steering=st-main
 /interface wifi configuration add country=Austria datapath=dp-guest mode=ap name=cfg-guest security=sec-guest ssid=dirtyvader-guest steering=st-guest
 /interface wifi capsman set ca-certificate=auto certificate=auto enabled=yes interfaces=vlan99 upgrade-policy=none
-# 🔴 ap1 hat BEWUSST keine Provisioning-Zeile (2026-08-30). ap3 hat in Technik UG seinen
+# ap1 ist ans Sideboard umgezogen (TP25-Kanalplan committed 2026-09-04) und hat wieder eine
-#    Platz uebernommen und funkt dort auf 5180; ap1 steht bis zu seinem Umzug ans Sideboard
+#    Provisioning-Zeile: Band B `5260/Ce` (5G) + ch1 (2,4G). Die frueher bewusst weggelassenen
-#    direkt daneben und wuerde auf demselben Kanal kollidieren. Ohne passende Regel legt
+#    Zeilen (2026-08-30, ap1 stand neben ap3 auf 5180 und haette kollidiert) sind damit
-#    CAPsMAN fuer ein Radio gar nichts an -> es bleibt still, das Geraet aber erreichbar.
+#    gegenstandslos. Reihenfolge wie am Geraet: ap2, ap3, ap1.
-#    Die Objekte `ch-5g-ap1`/`ch-2g-ap1` und `cfg-main-*-ap1` bleiben absichtlich stehen:
-#    beim Umzug bekommt ap1 laut TP25 `5260/Ce` (Band B, DFS) -- dann werden nur diese
-#    zwei Zeilen wieder eingesetzt und das Channel-Objekt auf eine Frequenz-LISTE gestellt
-#    (mit nur einem Wert waere eine Radar-Erkennung ein SPOF).
 /interface wifi provisioning 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
 /interface wifi provisioning 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
 /interface wifi provisioning add action=create-dynamic-enabled comment="ap3 5GHz" master-configuration=cfg-main-5g-ap3 radio-mac=D0:EA:11:FF:16:9F slave-configurations=cfg-media,cfg-untrusted,cfg-guest
 /interface wifi provisioning add action=create-dynamic-enabled comment="ap3 2.4GHz" master-configuration=cfg-main-2g-ap3 radio-mac=D0:EA:11:FF:16:A0 slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
+/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
+/interface wifi provisioning 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
 
 # [6c] WLAN ACCESS-LIST — der Soll-Zustand ist LEER, und das ist eine Aussage.
 #

routeros/tp28-ap3-phase2-cap.rsc

@@ -22,8 +22,13 @@
 /interface wifi datapath remove [find]
 /interface wifi channel remove [find]
 # Werks-Inline-Overrides auf den Master-Radios loeschen, sonst gewinnen sie gegen den Manager.
-/interface wifi set [find name=wifi1] !configuration.ssid !security.authentication-types !security.passphrase !security.ft-over-ds
+# 🔴 `!security.ft` MUSS mit dabei sein: die Werks-cAP-Radios kommen mit ft=yes; ohne diesen
-/interface wifi set [find name=wifi2] !configuration.ssid !security.authentication-types !security.passphrase !security.ft-over-ds
+#    unset bleibt er stehen und sendet dirtyvader-main mit FT, waehrend ap1/ap2 (ft geerbt=no)
+#    es nicht tun -> gemischtes FT-ESS, Strong-Signal-Abbrueche NUR auf ap3. Genau das war der
+#    Fall am 2026-09-04: die Abnahme unten zaehlt nur BENANNTE security-Objekte (=0) und sieht
+#    den Inline-Wert auf wifi1/wifi2 nicht. Nachtraeglich behoben 2026-09-04.
+/interface wifi set [find name=wifi1] !configuration.ssid !security.authentication-types !security.passphrase !security.ft !security.ft-over-ds
+/interface wifi set [find name=wifi2] !configuration.ssid !security.authentication-types !security.passphrase !security.ft !security.ft-over-ds
 
 # --- (2) L3-Reste des Werks-Routers weg (jetzt gefahrlos: die WLAN-Sitzung ist ohnehin tot) ---
 /ip dhcp-server remove [find]