From 40ffab1de87370452cd0284c693bd5c9dae35b86 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 31 Aug 2026 07:57:36 +0200 Subject: [PATCH] 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 --- CLAUDE.md | 6 +- docs/handoff-20260831-wlan-fund-e.md | 91 ++++++++++++++++++++++++++++ docs/teilprojekte.md | 13 ++++ 3 files changed, 108 insertions(+), 2 deletions(-) create mode 100644 docs/handoff-20260831-wlan-fund-e.md diff --git a/CLAUDE.md b/CLAUDE.md index 47ea9de..e3cc203 100644 --- a/CLAUDE.md +++ b/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. -5. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift. +4. 🔴 **WLAN/Fund E 2026-08-31:** [`docs/handoff-20260831-wlan-fund-e.md`](docs/handoff-20260831-wlan-fund-e.md) + — 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) diff --git a/docs/handoff-20260831-wlan-fund-e.md b/docs/handoff-20260831-wlan-fund-e.md new file mode 100644 index 0000000..fdacd06 --- /dev/null +++ b/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 `<>`). 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). diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 0593359..b845927 100644 --- a/docs/teilprojekte.md +++ b/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: