TP25 Fund E: Befund nach einer Nacht Logging -- Reauth-Schleife haengt an ft=yes, Hebelreihenfolge korrigiert

Das gestern eingeschaltete wireless-Logging hat binnen 16 h geliefert, was der 75-Zeilen-
Ringpuffer nie konnte: 559 Zeilen, davon 439 (79 %) von Christophs iPhone.

Entscheidend ist nicht die Menge, sondern die Trennschaerfe:
- `reauthenticating` tritt 93 von 93 Mal bei GENAU EINEM Client auf (dem iPhone)
- und 93 von 93 Mal auf GENAU EINER SSID (dirtyvader-main)
- was `main` von den anderen fuenf unterscheidet, ist EIN Attribut: ft=yes ft-over-ds=yes

Dieselben APs, dieselben Radios, derselbe Zeitraum, dieselben Clients -- die SSIDs mit
ft=no zeigen null Ereignisse. Das ist eine saubere Kontrollgruppe. Die WPA3+802.11r-
Hypothese, die ich gestern ausdruecklich als "Forenwissen, nicht in der MikroTik-Doku"
gefuehrt habe, ist damit durch eigene Messung gestuetzt.

Verlauf 2026-08-31 auf cap-wifi6: 07:25 (10x) -> 07:34 (21x), eskalierend, teils mehrere
pro Sekunde, endend mit einem Roam auf cap-wifi2 bei -89 dBm -- also der Flucht auf einen
25 dB schlechteren AP. Genau so sieht "Link weg trotz gutem Kontakt, dann Mobilfunk" von
der Infrastrukturseite aus.

KORREKTUR an meiner eigenen Priorisierung von gestern: 2g-probe-delay war als Hebel 1
gesetzt, weil es der ungefaehrlichste ist. Das war vor diesem Befund und ist falsch --
2g-probe-delay adressiert Band-Steering, hier liegt ein Authentifizierungsproblem vor.
Neue Reihenfolge: (1) ft-over-ds=no, (2) ft=no, (3) 2g-probe-delay, (4) signal-range.

Ebenfalls festgehalten: die zwei erfassten "not responding"-Abbruecke liegen bei -80/-76
dBm und sind NICHT dasselbe wie der Schwall -- die Ursprungsmessung vom 08-20 hatte -47.
Nicht zusammenwerfen.

Noch nichts am Funk geaendert. Der Hebel ist beschrieben, das Messrezept steht im Handoff,
und wifi-security ist nicht deploybar (TP22-Regel 1) -- die Aenderung muss am Geraet
erfolgen und das Template danach von Hand nachgezogen werden.

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

CLAUDE.md

@@ -9,8 +9,10 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
 1. **`docs/teilprojekte.md`** (Quick-Index-Block) — kanonischer Stand, Scope, Abhängigkeiten, **offene** TPs. **1 Read reicht.**
 2. **`docs/handoff-*.md`** (neueste) — wo die letzte Session aufgehört hat.
 3. Bei Live-Writes oder Inventur: **`docs/cf-tunnel-mapping.md`**, **`docs/teilprojekte-archiv.md`**.
-4. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
+4. 🔴 **WLAN/Fund E 2026-08-31:** [`docs/handoff-20260831-wlan-fund-e.md`](docs/handoff-20260831-wlan-fund-e.md)
-5. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
+   — Reauthentifizierungs-Schleife, **nur** auf der einzigen SSID mit `ft=yes`. Hebel liegt bereit.
+5. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
+6. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
 
 ## Was du sofort wissen musst (Inventur 2026-08-27)
 

docs/handoff-20260831-wlan-fund-e.md

@@ -0,0 +1,91 @@
+# Handoff 2026-08-31 — TP25 Fund E: der Befund liegt vor, der Hebel ist zu ziehen
+
+## Ausgangslage
+
+ap3 ist live und stabil (15 h+ verbunden, Kabel `ether2`→`core ether22` ist gezogen,
+`ether22` = `no-link`). Compliance **135/135, 0 Drifts** über 5 Geräte. Alles committet und
+gepusht (`fd05286`, `1006f91`, `1754862`).
+
+Am 2026-08-30 wurde WLAN-Logging persistent gemacht (`topics=wireless` + `topics=caps` vom Core
+in den TP5-Kollektor `10.40.20.18:514`, Tagesdateien unter
+`/opt/tp5-syslog/log/10.40.20.1/`). **Nach einer Nacht liegt der Befund vor.**
+
+## 🔴 Der Befund
+
+**559 `wireless`-Zeilen in ~16 h, davon 439 (79 %) von einem einzigen Gerät: Christophs iPhone
+`F2:62:4C:E1:AF:09`.**
+
+Entscheidend ist aber nicht die Menge, sondern die **Trennschärfe**:
+
+| Frage | Messung |
+|---|---|
+| Welche Clients erzeugen `reauthenticating`? | **93 von 93 = nur das iPhone.** Kein anderes Gerät im Netz. |
+| Auf welcher SSID? | **93 von 93 = nur `dirtyvader-main`.** |
+| Was unterscheidet `main` von den anderen fünf SSIDs? | **Genau ein Attribut: `ft=yes` + `ft-over-ds=yes`** (WPA3-PSK + 802.11r). `infra`/`iot`/`media`/`untrusted`/`guest` laufen mit `ft=no` → **null** Ereignisse. |
+
+Das ist eine saubere Kontrollgruppe: **dieselben APs, dieselben Radios, derselbe Zeitraum,
+dieselben Clients — nur die SSID mit Fast Transition zeigt das Verhalten.**
+
+**Verlauf des Schwalls am 2026-08-31 auf `cap-wifi6` (ap3, 2,4 GHz):**
+
+```
+07:25  10 ×        07:31   9 ×        07:33  14 ×
+07:27   1 ×        07:32  17 ×        07:34  21 ×
+07:30   6 ×
+07:34:42  → roamed to cap-wifi2, signal strength -89
+```
+
+Eskalierende Reauthentifizierung, teils mehrere pro Sekunde, endend mit der Flucht auf einen
+**25 dB schlechteren** AP. Genau so sieht „Link weg trotz gutem Kontakt, danach Mobilfunk" von
+der Infrastrukturseite aus.
+
+Zusätzlich erfasst: zwei `disconnected, not responding` am 30.08. um 21:47 und 22:10 — aber bei
+**−80/−76 dBm**, also grenzwertigem Signal. ⚠️ **Die sind NICHT dasselbe** wie der Schwall und
+sollten nicht zusammengeworfen werden (die Ursprungsmessung vom 08-20 hatte −47 dBm).
+
+## ⚠️ Korrektur an der Hebel-Reihenfolge vom 2026-08-30
+
+Der Plan von gestern setzte **`2g-probe-delay=yes`** als Hebel 1, weil es der ungefährlichste ist.
+**Das war vor diesem Befund und ist jetzt falsch:** `2g-probe-delay` adressiert **Band-Steering**,
+hier liegt aber ein **Authentifizierungsproblem** vor. Neue Reihenfolge:
+
+| # | Hebel | Begründung | Risiko |
+|---|---|---|---|
+| **1** | **`ft-over-ds=no`** auf `sec-main` | Nimmt genau die Änderung vom 2026-08-17 zurück (Standalone fuhr `ft-over-ds=no`). FT bleibt over-the-air via `ft=yes`. **Kleinster Eingriff, der die verdächtige Achse trifft.** | gering |
+| 2 | **`ft=no`** auf `sec-main` | Falls (1) nicht reicht: FT komplett aus. Kostet Roaming-Geschwindigkeit, nicht Roaming. | mittel |
+| 3 | `2g-probe-delay=yes` | Erst danach — adressiert die **Band-Oszillation**, ein anderes Symptom | sehr gering |
+| 4 | `signal-range`-Boden (Fund E im Original) | invasivster Hebel, **kann Clients aussperren**. Nur mit gemessenem Wert. | hoch |
+
+**Vorgehen:** ein Hebel, dann 24 h messen, dann entscheiden. Jeder als Transaktion:
+`python3 nautobot/gc-transaktion.py begin --device crs326-core --scope wifi-security --change-id … --expires …`
+
+🔴 **`wifi-security` ist NICHT deploybar** (TP22-Regel 1: maskierte Sektionen sind vom Push
+ausgeschlossen — die Passphrasen stehen im Template als `<<REDACTED>>`). Die Änderung muss also
+**am Gerät** erfolgen und danach per REST zurückgelesen werden, und das GC-Template ist
+anschließend von Hand nachzuziehen. Siehe Kommentar in `mikrotik_routeros.j2` [6b].
+
+## Wie man die Wirkung misst
+
+```bash
+# Basislinie und Kontrolle, beides aus dem Kollektor:
+ssh root@10.40.20.100 "pct exec 400 -- sh -c '
+  cat /opt/tp5-syslog/log/10.40.20.1/2026-0*-*.log |
+  grep reauthenticating | grep -oE \"([0-9A-F]{2}:){5}[0-9A-F]{2}\" | sort | uniq -c'"
+```
+**Erfolgskriterium:** `reauthenticating` für `F2:62:4C:E1:AF:09` geht auf ~0 zurück, **ohne** dass
+die anderen SSIDs neue Ereignisse zeigen. Die Zahl muss sich **bewegen** — bleibt sie gleich, hat
+der Hebel nicht gegriffen (dieselbe Merkregel wie bei den Compliance-Zahlen).
+
+## Ebenfalls offen
+
+1. **TP25-Messrunde** — `bash docs/tp25-runde.sh ap3-bringup`, dann `docs/tp25-walk-messung.sh`.
+   Braucht einen Rundgang. Frage: deckt ap3 allein ab, was ap1 abgedeckt hat?
+2. **Passwort-Rotation (TP30)** — das gemeinsame Admin-PW ist am 2026-08-30 im Transkript
+   verbrannt. ap3 trägt es mit. Zusätzlich fehlen in `~/.secrets/exports.zsh`:
+   `MCP_MIKROMCP_ROUTER_AP3_PASS`, `MCP_MIKROMCP_CRS326_CORE_PASS`, `MCP_MIKROMCP_CRS326_BRANCH_PASS`.
+3. **MikroMCP-Neustart** — Registry (jetzt `bf-infra`, inkl. ap3) wird nur beim Start gelesen.
+4. **ap1-Umzug ans Sideboard** — Uplink auf `core ether3` (dort vorher die VLAN40-Altlast
+   abräumen), Kanal `5260/Ce`. TP25-Auflagen: **Frequenz-LISTE** statt Einzelwert (Radar sonst
+   SPOF) und **vorher `tx-power` messen** (Fund B: 18 dBm gesetzt, 9 gesendet).
+5. **Versions-Angleichung** — ap3 auf 7.24.1, die anderen vier auf 7.24 (eigener TP27-Durchgang,
+   Core-Reboot = Standort-Ausfall).

docs/teilprojekte.md

@@ -1350,6 +1350,19 @@ den Kollektor (`10.40.20.18:514`, dieselbe Senke wie TP5), und `/system logging`
 unter der **27. ComplianceRule `system-logging`** — vorher war der Block unter keiner Regel und im
 Template gar nicht vorhanden. Vorher lief alles nur in einen 75-Zeilen-Ringpuffer.
 
+**🔴 NACHTRAG 2026-08-31 — die Daten sind da, und sie kippen die Reihenfolge.** Nach einer Nacht
+Logging: **559 `wireless`-Zeilen, 439 davon (79 %) vom iPhone.** Entscheidend ist die Trennschärfe —
+`reauthenticating` tritt **93 von 93 Mal bei genau einem Client** auf (dem iPhone) und **93 von 93
+Mal auf genau einer SSID** (`dirtyvader-main`). Was `main` von den anderen fünf unterscheidet, ist
+**ein einziges Attribut: `ft=yes ft-over-ds=yes`**. Dieselben APs, dieselben Radios, derselbe
+Zeitraum — die SSIDs mit `ft=no` zeigen **null** Ereignisse. Das ist eine saubere Kontrollgruppe;
+die WPA3+802.11r-Hypothese ist damit **durch eigene Messung gestützt**, nicht mehr Forenwissen.
+Verlauf am 31.08.: 07:25 (10×) → 07:34 (21×), eskalierend, teils mehrere pro Sekunde, endend mit
+der Flucht auf einen **25 dB schlechteren** AP (`-89 dBm`).
+⇒ **`ft-over-ds=no` ist jetzt Hebel 1**, nicht `2g-probe-delay`: Letzteres adressiert
+Band-Steering, hier liegt ein **Authentifizierungs**problem vor. Details und Messrezept im
+[Handoff vom 2026-08-31](handoff-20260831-wlan-fund-e.md).
+
 **🚫 Kein Funk-Parameter wird geändert, solange keine Daten da sind.** Drei Hebel, **einzeln** und je
 als Transaktion (`gc-transaktion.py`), in dieser Reihenfolge: