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: