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