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

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

# 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).