Christoph Emsenhuber
40ffab1de8
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>
92 lines
5.1 KiB
Markdown
92 lines
5.1 KiB
Markdown
# 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).
|