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

@@ -17,8 +17,17 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
    — die Abschlussmessung ergab am 09-02 nur **4 `reauthenticating` in 8,6 h** (alle iPhone `F2:62`,
    isolierte Einzel, 0 Ausfaelle), Verlauf **218 → 40 → 4**; Vorbedingung geprueft (Core-Uptime 1d18h,
    `caps joined=0`). Hebel 1 (`ft-over-ds=no`) war widerlegt (6,4 h allein → 124× + 2 Ausfaelle) und ist
-   am 09-01 zurueckgebaut; Hebel 2–4 entfallen, **kein Geraete-Write** (Soll steht: `ft=yes ft-over-ds=yes`,
-   **Compliance 140/140**). Offen in TP25 bleibt nur **ap2 unterperformt** (2 m/−80 dBm). Vorstufen:
+   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) ·
    [Rueckbau](docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md).

docs/teilprojekte.md

@@ -28,7 +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 140/140** (nach TP42, 2026-09-02).
+**Compliance 140/140, 0 Drifts** (2026-09-04 nachmittags). Der TP25-Kanalplan ist **committed**:
+Template auf DFS-Frequenz-Listen umgestellt (`ch-5g-ap1=5260,5280`, `ch-5g-ap2=5300,5320`) + die
+ap1-Provisioning-Zeilen wieder aufgenommen → Transaktion `TP25-kanalplan-ap1-live` geschlossen und der
+`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
@@ -41,7 +47,16 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   `reauthenticating` am 09-02 nur noch **4 in 8,6 h** (alle iPhone `F2:62`, isolierte Einzel, 0 Ausfälle)
   gegen Baseline 93 bzw. Hebel-1 **19/h**. Verlauf **218 → 40 → 4**; Vorbedingung geprüft (Core-Uptime
   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**. Offen in
+  `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). 🔴 **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,
@@ -268,7 +283,8 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
 - **WLAN = CAPsMAN auf dem Core** (TP28 ✅ 08-17, GC-Modell nachgezogen 08-18): ap1 **`10.40.99.11`**
   (an core `ether15`), ap2 **`10.40.99.12`** (an branch `ether24`), beide **reine CAPs** —
   `cap enabled=yes`, `discovery-interfaces=vlan99`. Die APs halten **keine eigene WLAN-Config** mehr;
-  Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
+  Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11k/v aktiv; **802.11r (FT) aus** —
+  `ft=no` auf allen SSIDs (sec-main seit 2026-09-04, User-Entscheid).
   🆕 **Dritter AP `ap3` (cAP ax) ✅ LIVE seit 2026-08-30** (TP28 dafür wieder geöffnet):
   `10.40.99.13`, Uplink `ether1` → **core `ether21`** (Trunk), reiner CAP, **RouterOS 7.24.1**
   (🆕 **seit 2026-08-31 die ganze Flotte** — die frühere Versionsdifferenz ist aufgelöst). Kanäle
@@ -512,7 +528,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — |
 > | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
 > | TP24 | 🔜 | DC-USV | — |
-> | TP25 | ⏳ | WLAN-Stabilisierung (Kern ✅) — **Fund E ✅ geschlossen 09-02: 7.24.1 war die Ursache, nicht `ft-over-ds` (4/8,6 h, 0 Ausfälle)**; **Konsole auf N Clients + Pin-UI ✅ 09-04**; offen nur ap2 unterperformt (2 m/−80, In-situ) | 2026-09-04 |
+> | TP25 | ⏳ | WLAN-Stabilisierung (Kern ✅) — **Fund E ✅ geschlossen 09-02: 7.24.1 war die Ursache, nicht `ft-over-ds` (4/8,6 h, 0 Ausfälle)**; **`ft=no` auf `sec-main` als Dauerzustand ✅ 09-04**; **Konsole auf N Clients + Pin-UI ✅ 09-04**; offen nur ap2 unterperformt (2 m/−80, In-situ) | 2026-09-04 |
 > | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
 > | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
 > | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
@@ -1772,7 +1788,7 @@ die alte Liste führte `2g-probe-delay` an, das aber **Band-Steering** adressier
 | # | Hebel | Begründung der Reihenfolge | Risiko | Stand |
 |---|---|---|---|---|
 | 1 | **`ft-over-ds=no`** auf `sec-main` | nimmt die Änderung vom 08-17 zurück; FT bleibt über `ft=yes` (over-the-air) erhalten. Kleinster Eingriff, der die verdächtige Achse trifft | gering | ❌ **widerlegt** — lief 6,4 h allein → 124× (≈19/h) + 2 Ausfälle, **zurückgebaut 2026-09-01** |
-| 2 | `ft=no` auf `sec-main` | falls (1) nicht reicht: FT komplett aus. Kostet Roaming-*Geschwindigkeit*, nicht Roaming | mittel | ⏹️ entfällt — 7.24.1 löste Fund E (Messung 09-02) |
+| 2 | `ft=no` auf `sec-main` | falls (1) nicht reicht: FT komplett aus. Kostet Roaming-*Geschwindigkeit*, nicht Roaming | mittel | ✅ **gezogen 2026-09-04** (User-Entscheid, Dauerzustand — Template + bf-golden-config + Nautobot-Sync) |
 | 3 | `2g-probe-delay=yes` (2,4-GHz-Configs) | MikroTiks *dafür gebautes* Werkzeug; verzögert nur Probe-Antworten und **kann keinen Client stranden lassen**. Adressiert die **Band-Oszillation** — ein anderes Symptom | sehr gering | ⏹️ entfällt (Fund E geschlossen) |
 | 4 | `signal-range`-Boden per `access-list` (Fund E im Original) | **kann Clients aussperren** — genau das war 08-22 das Gegenargument; nur mit gemessenem Wert | hoch | ⏹️ entfällt (Fund E geschlossen) |
 
@@ -1780,7 +1796,8 @@ die alte Liste führte `2g-probe-delay` an, das aber **Band-Steering** adressier
 > `ft-over-ds=yes` **und** 7.24.1 verschwunden — 09-02 nur **4 reauth in 8,6 h** (alle iPhone `F2:62`, isolierte
 > Einzel, 0 Ausfälle), Verlauf **218 → 40 → 4**. Vorbedingung geprüft (Core-Uptime 1d18h, `caps joined=0`).
 > ⇒ **7.24.1 war die Ursache/der Fix, nicht `ft-over-ds`.** Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen,
-> **kein Geräte-Write** (Soll steht: `ft=yes ft-over-ds=yes`, Compliance 140/140). Der folgende Detailblock zu
+> **kein Geräte-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). Der folgende Detailblock zu
 > Hebel 1 ist historisch.
 
 #### 🔬 Hebel 1 — gezogen am 2026-08-31 08:09, Messung läuft bis 2026-09-01

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
-/interface wifi channel add band=5ghz-ax frequency=5220 name=ch-5g-ap2 width=20/40mhz
+# ap1/ap2 auf Band B (DFS) seit dem TP25-Kanalplan-Umzug (committed 2026-09-04). Frequenz-LISTE
+# 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:
@@ -219,7 +222,10 @@
 /interface wifi datapath add bridge=bridge name=dp-media vlan-id=40
 /interface wifi datapath add bridge=bridge name=dp-untrusted vlan-id=50
 /interface wifi datapath add bridge=bridge name=dp-guest vlan-id=90
-/interface wifi security add authentication-types=wpa3-psk ft=yes ft-over-ds=yes name=sec-main passphrase="<<REDACTED>>"
+# sec-main: ft=no seit 2026-09-04 (User-Entscheid nach TP25-Messung). Fast-Transition
+# komplett aus; ft-over-ds ist damit gegenstandslos (gilt nur bei ft=yes) und steht auf no.
+# Fund E hatte ft-over-ds=no BEI ft=yes widerlegt -- das hier ist ein anderer Hebel (FT aus).
+/interface wifi security add authentication-types=wpa3-psk ft=no ft-over-ds=no name=sec-main passphrase="<<REDACTED>>"
 /interface wifi security add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-infra passphrase="<<REDACTED>>"
 /interface wifi security add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-iot passphrase="<<REDACTED>>"
 /interface wifi security add authentication-types=wpa2-psk,wpa3-psk ft=no name=sec-media passphrase="<<REDACTED>>"
@@ -241,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
-#    Platz uebernommen und funkt dort auf 5180; ap1 steht bis zu seinem Umzug ans Sideboard
-#    direkt daneben und wuerde auf demselben Kanal kollidieren. Ohne passende Regel legt
-#    CAPsMAN fuer ein Radio gar nichts an -> es bleibt still, das Geraet aber erreichbar.
-#    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).
+# ap1 ist ans Sideboard umgezogen (TP25-Kanalplan committed 2026-09-04) und hat wieder eine
+#    Provisioning-Zeile: Band B `5260/Ce` (5G) + ch1 (2,4G). Die frueher bewusst weggelassenen
+#    Zeilen (2026-08-30, ap1 stand neben ap3 auf 5180 und haette kollidiert) sind damit
+#    gegenstandslos. Reihenfolge wie am Geraet: ap2, ap3, ap1.
 /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
-/interface wifi set [find name=wifi2] !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
+#    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]