From a0a650eb489123585b52691b351c6624b898beed Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 31 Aug 2026 08:19:31 +0200 Subject: [PATCH] TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main, Messung laeuft Ein Hebel, sonst nichts. 2026-08-31 08:09 am Manager crs326-core: /interface wifi security set [find name="sec-main"] ft-over-ds=no /interface wifi capsman remote-cap provision [find] ft=yes bleibt -- FT laeuft weiter over-the-air, nur nicht mehr over-the-DS. Nimmt exakt die Aenderung vom 2026-08-17 zurueck. Abnahme (Lease, nicht Registration-Table): - Manager, alle vier aktiven Master-VAPs cap-wifi3/4/5/6: ft=true ft-over-ds=false - alle 3 CAPs state=Ok, alle VAPs running=yes AM CAP gelesen - iPhone nach 71 s zurueck auf dirtyvader-main, frische Lease 10.40.10.196, auth-type=ft-wpa3-psk, -54 dBm; 30 Clients gesamt zurueck - Log 08:13:20 zeigt sauberes "roamed to" zwischen zwei APs -> Roaming intakt - Geraete-Backup vorher: pre-tp25-funde-ftoverds.backup Governance: Transaktion TP25-fund-e-ft-over-ds OFFEN (Scope wifi-security, Ablauf 2026-09-03). Compliance steht deshalb ABSICHTLICH auf 134/135; der Diff ist exakt ft-over-ds=yes->no, kein Kollateral-Drift durch die Re-Provisionierung. Das GC-Template wird erst beim COMMIT nachgezogen -- vorher gruen machen wuerde den laufenden Versuch unsichtbar machen, und gc-transaktion.py verweigert den Commit ohnehin, solange der Scope driftet. 135/135 kommt nach der Messung zurueck. Messstand nach 25 min: weiter 93, letzter reauthenticating 07:34:43 (vor dem Eingriff). Logging nachweislich lebendig (593 wireless-Zeilen heute, beide SSIDs). Noch kein Ergebnis, nur ein sauberer Schnitt. Drei Funde: - cap-wifiN-Karte hat sich beim Re-Provisionieren VERSCHOBEN: ap2 war 1/2 -> jetzt 3/5, ap3 war 5/6 -> jetzt 4/6, ap1 hat 1/2 bekommen. Wer die 07:xx-Zeilen gegen die neuen liest, ordnet dem falschen AP zu. - Korrektur am Vormittagsbefund: main unterscheidet sich in ZWEI Attributen, nicht einem -- es ist auch die einzige SSID ohne wpa2-psk. Die Kontrollgruppe trennt FT und WPA3-only nicht. Wenn Hebel 1 und 2 beide nichts bewegen, ist authentication-types der naechste Kandidat, NICHT signal-range. - gc-transaktion.py rief sshpass -p auf (Passwort in argv, Klasse vom 2026-08-22). Auf SSHPASS-Env + -e umgestellt, weil das Skript laufen musste. Fuenf weitere Dateien unter routeros/ haben dasselbe Muster und sind bewusst NICHT angefasst (Stop-Bedingung; gehoert zu TP30). Entwarnung: /export auf 7.24 gibt Passphrasen gar nicht aus (live geprueft), die Transaktionsakte im Git ist sauber. Nebenbei: .gitignore hatte docs/nas-vlan20/stacks/ MIT Schraegstrich -- im Worktree liegt dort ein Symlink auf den Haupt-Checkout, der war damit nicht ignoriert. Doku an allen drei Stellen nachgezogen (Quick-Index, TP25-Abschnitt, Ist-Stand-Block) plus CLAUDE.md-Pflichtlektuere und neuer Handoff mit Entscheidungstabelle fuer 09-01. Co-Authored-By: Claude Opus 5 --- .gitignore | 5 +- CLAUDE.md | 7 +- .../handoff-20260831-fund-e-hebel1-gezogen.md | 140 ++++++++++++++++++ docs/teilprojekte.md | 83 +++++++++-- .../transaktionen/TP25-fund-e-ft-over-ds.json | 14 ++ .../TP25-fund-e-ft-over-ds.snapshot.rsc | 11 ++ nautobot/gc-transaktion.py | 8 +- 7 files changed, 251 insertions(+), 17 deletions(-) create mode 100644 docs/handoff-20260831-fund-e-hebel1-gezogen.md create mode 100644 docs/transaktionen/TP25-fund-e-ft-over-ds.json create mode 100644 docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc diff --git a/.gitignore b/.gitignore index 79f7c52..1b80a71 100644 --- a/.gitignore +++ b/.gitignore @@ -10,7 +10,10 @@ __pycache__/ *.pyc # NAS-VLAN20-Migration: Compose-Files/Inspects enthalten Live-Secrets → nicht committen -docs/nas-vlan20/stacks/ +# 🔴 OHNE Schraegstrich: mit `stacks/` greift die Regel nur auf ein echtes Verzeichnis. In einem +# git-worktree liegt hier ein SYMLINK auf den Haupt-Checkout (die Datei ist gitignored und +# existiert deshalb nur dort) — und der war damit nicht ignoriert. Gefunden 2026-08-31. +docs/nas-vlan20/stacks docs/nas-vlan20/inspect_*.json # RouterOS-Config-Exports/Backups enthalten Live-Secrets (WiFi-Passphrasen etc.) → nicht committen diff --git a/CLAUDE.md b/CLAUDE.md index e3cc203..e07ad79 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -9,8 +9,11 @@ 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. 🔴 **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. +4. 🔴 **WLAN/Fund E — LAUFENDER VERSUCH:** [`docs/handoff-20260831-fund-e-hebel1-gezogen.md`](docs/handoff-20260831-fund-e-hebel1-gezogen.md) + — Hebel 1 (`ft-over-ds=no` auf `sec-main`) ist am **2026-08-31 08:09** gezogen, Transaktion + `TP25-fund-e-ft-over-ds` ist **offen**, **Compliance steht deshalb absichtlich auf 134/135**. + Einzige offene Aufgabe: **messen und entscheiden** (24 h). Befund davor: + [`docs/handoff-20260831-wlan-fund-e.md`](docs/handoff-20260831-wlan-fund-e.md). 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. diff --git a/docs/handoff-20260831-fund-e-hebel1-gezogen.md b/docs/handoff-20260831-fund-e-hebel1-gezogen.md new file mode 100644 index 0000000..6da54ed --- /dev/null +++ b/docs/handoff-20260831-fund-e-hebel1-gezogen.md @@ -0,0 +1,140 @@ +# Handoff 2026-08-31 — TP25 Fund E: Hebel 1 ist gezogen, die Uhr läuft + +> Vorgänger: [`handoff-20260831-wlan-fund-e.md`](handoff-20260831-wlan-fund-e.md) (Befund + Messrezept). +> **Dieses Dokument ist der Stand danach.** Es gibt genau eine offene Aufgabe: **messen und entscheiden.** + +## Was am 2026-08-31 um 08:09 passiert ist + +**Eine** Änderung, sonst nichts: + +``` +/interface wifi security set [find name="sec-main"] ft-over-ds=no # vorher: yes +/interface wifi capsman remote-cap provision [find] +``` + +`ft=yes` bleibt — Fast Transition läuft weiter **over-the-air**, nur nicht mehr **over-the-DS**. Das +nimmt exakt die Änderung vom 2026-08-17 zurück, mehr nicht. **Kein weiterer Funk-Parameter ist +angefasst worden** (Stop-Bedingung: wer zwei Hebel zieht, weiß hinterher nichts). + +## Abnahme — was tatsächlich geprüft wurde + +| Prüfung | Ergebnis | +|---|---| +| Wirkt der Hebel? **am Manager, alle Master-VAPs** | `cap-wifi3/4/5/6` → `ft=true ft-over-ds=false`. `cap-wifi1/2` (= ap1) leer, weil ap1 funkstill ist. | +| CAPs zurück? | alle drei `state=Ok` | +| VAPs laufen? **am CAP gelesen**, nicht am Manager | ap2 und ap3: alle 9 Interfaces `running=yes` | +| **Frische DHCP-Lease** (die vorgeschriebene Abnahme) | iPhone `F2:62:4C:E1:AF:09` nach 71 s wieder auf `dirtyvader-main`, `10.40.10.196`, **`auth-type=ft-wpa3-psk`**, −54 dBm | +| Clients gesamt | 30 zurück | +| Roaming funktioniert noch? | ja — Log zeigt um 08:13:20 ein sauberes `roamed to` zwischen zwei APs auf `main` | +| Compliance | **134/135**, Diff **exakt** `ft-over-ds=yes → no`. **Kein Kollateral-Drift.** | + +Geräte-Backup vor dem Eingriff: `pre-tp25-funde-ftoverds.backup` auf dem Core (08:07:58). + +## 🔴 Warum Compliance auf 134/135 steht und das RICHTIG ist + +Die Transaktion **`TP25-fund-e-ft-over-ds`** ist **offen** (Scope `wifi-security`, Ablauf +**2026-09-03**). `gc-transaktion.py status` weist den einen Drift als **erwartet** aus — genau dafür +gibt es das Werkzeug. + +**Das Template wird bewusst NICHT vorher nachgezogen.** Wer es jetzt grün macht, macht den laufenden +Versuch unsichtbar, und `status` kann ihn nicht mehr von einem Versehen unterscheiden. `gc-transaktion.py` +erzwingt die richtige Reihenfolge ohnehin: es verweigert den Commit, solange der Scope driftet. +**135/135 kommt beim Commit zurück** — nach der Messung, nicht davor. + +## 🔴 Die `cap-wifiN`-Karte hat sich beim Re-Provisionieren VERSCHOBEN + +Wer die Logs vom 31.08. auswertet und das übersieht, ordnet Ereignisse dem falschen AP zu: + +| | vor 08:09 (Logzeilen 07:xx) | ab 08:09 | +|---|---|---| +| ap1 (funkstill) | — | `cap-wifi1` / `cap-wifi2` | +| ap2 | `cap-wifi1` / `cap-wifi2` | `cap-wifi3` / `cap-wifi5` | +| ap3 | `cap-wifi5` / `cap-wifi6` | `cap-wifi4` / `cap-wifi6` | + +Gelesen mit `/interface wifi radio print` am Manager. Das ist dieselbe Instabilität, die +[`tp25-walk-messung.sh`](tp25-walk-messung.sh) als `ap-map.txt` einfriert — hier von Hand. + +## ⚠️ Korrektur am Befund vom Vormittag + +Der Vorgänger-Handoff sagt, `main` unterscheide sich von den anderen fünf SSIDs in **genau einem** +Attribut. **Live nachgelesen sind es zwei:** + +``` +sec-main authentication-types=wpa3-psk ft=yes ft-over-ds=yes +sec-infra … authentication-types=wpa2-psk,wpa3-psk ft=no +``` + +`sec-main` ist **auch die einzige SSID ohne `wpa2-psk`**. Die Kontrollgruppe trennt FT und WPA3-only +also **nicht** voneinander. Das ändert die Hebelreihenfolge nicht — die Hypothese nennt gerade die +Kombination WPA3+FT — aber es ändert den Plan B: + +⇒ **Wenn Hebel 1 und Hebel 2 (`ft=no`) beide nichts bewegen, ist der nächste Kandidat +`authentication-types=wpa2-psk,wpa3-psk` auf `sec-main` — NICHT `signal-range`.** + +## Die einzige offene Aufgabe: messen + +```bash +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'" +``` + +**Baseline: 93**, alle vom iPhone `F2:62:4C:E1:AF:09`, alle auf `dirtyvader-main`. +Davon **79 am 31.08., sämtlich in Stunde 07**, der letzte um **07:34:43** — also **vor** dem Eingriff. +Zwischen 08:00 und 08:15 kein einziges. **Das ist noch kein Ergebnis, nur der saubere Schnitt.** + +Ein Gegencheck gehört dazu — er beweist, dass nicht einfach das Logging kaputt ist: + +```bash +ssh root@10.40.20.100 "pct exec 400 -- sh -c ' + grep wireless /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log | wc -l; + grep wireless /opt/tp5-syslog/log/10.40.20.1/2026-09-01.log | grep -oE \"\\(dirtyvader-[a-z]+\\)\" | sort | uniq -c'" +``` + +### Die Entscheidung am 2026-09-01 + +| Messung | Schluss | Nächster Schritt | +|---|---|---| +| iPhone-`reauthenticating` **~0**, andere SSIDs unverändert | Hebel 1 hat gegriffen | Template `mikrotik_routeros.j2` Z. 220 auf `ft-over-ds=no` ziehen → `gc-transaktion.py commit --change-id TP25-fund-e-ft-over-ds` → Compliance zurück auf 135/135 | +| Zahl **unverändert** | Hebel 1 hat **nicht** gegriffen | Rollback ODER stehen lassen und **Hebel 2 `ft=no`** als eigene Transaktion. Nicht beides gleichzeitig. | +| Zahl runter, aber neue Ereignisse auf anderen SSIDs | Nebenwirkung | Rollback, dann neu bewerten | + +Rollback-Weg (der Snapshot liegt bereit): +`python3 nautobot/gc-transaktion.py rollback --change-id TP25-fund-e-ft-over-ds` +— erzeugt einen **Vorschlag**, der gelesen werden will, und pusht bewusst nicht selbst. + +## 🔧 Nebenbefund: `sshpass -p` in sechs Skripten + +`nautobot/gc-transaktion.py` rief `sshpass -p ` auf — das schreibt das Passwort in `argv`, wo es +in `ps` und jedem argv-Trace steht. Das ist die Klasse, an der am 2026-08-22 das Core-Passwort +verbrannt ist, und CLAUDE.md verbietet sie ausdrücklich. **In `gc-transaktion.py` behoben** +(`SSHPASS`-Env + `-e`), weil das Skript für diese Aufgabe laufen musste. + +🔴 **Fünf weitere Dateien haben dasselbe Muster und sind NICHT angefasst** (Stop-Bedingung — +gehört in eine eigene Runde, sinnvollerweise mit TP30): + +``` +routeros/import-core-rsc.py Z. 50, 74 +routeros/apply-core-cutover-l3.py Z. 29, 55 +routeros/backup-core.py Z. 29, 41 +routeros/restore-core.py Z. 30, 42 +routeros/backup-ap1.py Z. 29, 41 +``` + +**Entwarnung zum Snapshot:** `/export` auf ROS 7.24 gibt WLAN-Passphrasen **gar nicht** aus +(0 Vorkommen im Vollexport, live geprüft). Die Transaktionsakte im Git ist sauber. + +## 🔧 Zweiter Nebenbefund: Worktrees können `gc-*.py` nicht ohne Handgriff ausführen + +`docs/nas-vlan20/stacks/210-nautobot.yml` ist gitignored und existiert deshalb **nur im +Haupt-Checkout**. In einem Worktree scheitern `gc-transaktion.py` und `gc-configplan.py` am +Nautobot-Token. Behelf in dieser Session war ein Symlink auf den Haupt-Checkout — **der gehört nicht +committet**. Dauerhafte Antwort wäre `NAUTOBOT_TOKEN` aus `~/.secrets/exports.zsh` (gc-configplan +liest die Variable bereits; gc-transaktion liest nur die Stack-Datei). + +## Unverändert offen (nicht Teil dieser Session) + +1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — ⚠️ **die `ap-map` neu einfrieren**, s.o. +2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt; fehlende `MCP_MIKROMCP_*_PASS` in `exports.zsh`) +3. MikroMCP-Neustart (Registry inkl. ap3 wird nur beim Start gelesen) +4. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste** statt Einzelwert, `tx-power` vorher messen) +5. Versions-Angleichung 7.24 → 7.24.1 diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index b845927..700713a 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -108,11 +108,22 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d - 🆕 **WLAN-Logging persistent seit 2026-08-30 (TP25 Fund E):** `wireless` + `caps` gehen vom Core in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule** `system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend - nicht diagnostizierbar. **Fund E ist wieder offen**, Funk-Parameter werden bis zur Datengrundlage - bewusst **nicht** angefasst. + nicht diagnostizierbar. +- 🔬 **TP25 Fund E — Hebel 1 läuft seit 2026-08-31 08:09 (LAUFENDER VERSUCH, nicht Endstand):** + `sec-main` steht am Core auf **`ft=yes ft-over-ds=no`** (vorher `yes/yes`). Belegt am Manager an + allen vier aktiven Master-VAPs (`cap-wifi3/4/5/6`). Transaktion + **`TP25-fund-e-ft-over-ds`** ist **OFFEN** (Scope `wifi-security`, Ablauf **2026-09-03**), + Geräte-Backup `pre-tp25-funde-ftoverds.backup` liegt auf dem Core. + ⇒ **Compliance steht deshalb bewusst auf 134/135** — der eine Drift ist genau dieser Versuch und + wird von `gc-transaktion.py status` als *erwartet* ausgewiesen. **135/135 kommt beim COMMIT + zurück**, nachdem 24 h gemessen sind und das Template nachgezogen ist; das Skript verweigert den + Commit ohnehin, solange der Scope driftet. Baseline zum Vergleich: **93× `reauthenticating`**, + 93/93 vom iPhone `F2:62:4C:E1:AF:09`, 93/93 auf `dirtyvader-main`. - **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 5 Geräte in der Registry), **Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf, - **135/135 Compliance-Checks grün, 0 Drifts** bei **27 Rules × 5 Geräten** (Stand 2026-08-30) — live gegen die API + **135/135 Compliance-Checks grün, 0 Drifts** bei **27 Rules × 5 Geräten** (Stand 2026-08-30; + **seit 2026-08-31 vorübergehend 134/135 — der eine Drift ist die offene Transaktion + `TP25-fund-e-ft-over-ds`, s. oben, kein Fehler**) — live gegen die API geprüft am **2026-08-23**; zuletzt dazugekommen: **`wifi-access-list`** (08-22), **`queue`** (08-23, TP6) und **`ip-firewall-mangle`** (08-23, TP6.1), s. TP22-Nachtrag im Archiv). *(Hier stand bis zum 08-23 „100/100 bei 25 Rules" — eine Zählung, die TP6.1 am selben Tag überholt @@ -249,7 +260,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na > | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — | > | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 | > | TP24 | 🔜 | DC-USV | — | -> | TP25 | ✅ | WLAN-Stabilisierung (Kern erledigt) | 2026-08-24 | +> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E offen, Hebel 1 `ft-over-ds=no` läuft, Messung bis 09-01** | 2026-08-31 | > | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 | > | TP29 | 💡 | Anwesenheitserkennung (Idee) | — | > | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — | @@ -1119,7 +1130,7 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.** - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen). -### TP25 — WLAN-Stabilisierung ▸ 🟢 **KERN ERLEDIGT (2026-08-22): Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6 +### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E OFFEN, HEBEL 1 LÄUFT (2026-08-31 08:09): `ft-over-ds=no` auf `sec-main`, Messung bis 2026-09-01** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6 > 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen > 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv: > [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G), @@ -1363,14 +1374,62 @@ der Flucht auf einen **25 dB schlechteren** AP (`-89 dBm`). 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: +**🚫 Kein Funk-Parameter wird geändert, solange keine Daten da sind.** Vier Hebel, **einzeln** und je +als Transaktion (`gc-transaktion.py`). **Reihenfolge korrigiert am 2026-08-31** durch den Befund oben — +die alte Liste führte `2g-probe-delay` an, das aber **Band-Steering** adressiert, während hier ein +**Authentifizierungs**problem gemessen ist: -| # | Hebel | Begründung der Reihenfolge | Risiko | -|---|---|---|---| -| 1 | `2g-probe-delay=yes` (2,4-GHz-Configs) | MikroTiks *dafür gebautes* Werkzeug; verzögert nur Probe-Antworten und **kann keinen Client stranden lassen** | sehr gering | -| 2 | `ft-over-ds=no` auf `sec-main` | nimmt die Änderung vom 08-17 zurück; FT bleibt über `ft=yes` (over-the-air) erhalten | gering | -| 3 | `signal-range`-Boden per `access-list` (Fund E im Original) | **kann Clients aussperren** — genau das war 08-22 das Gegenargument; nur mit gemessenem Wert | hoch | +| # | Hebel | Begründung der Reihenfolge | Risiko | Stand | +|---|---|---|---|---| +| 1 | **`ft-over-ds=no`** auf `sec-main` | nimmt die Änderung vom 08-17 zurück; FT bleibt über `ft=yes` (over-the-air) erhalten. Kleinster Eingriff, der die verdächtige Achse trifft | gering | 🔬 **gezogen 2026-08-31 08:09**, Messung läuft | +| 2 | `ft=no` auf `sec-main` | falls (1) nicht reicht: FT komplett aus. Kostet Roaming-*Geschwindigkeit*, nicht Roaming | mittel | 🔜 nur wenn (1) nicht greift | +| 3 | `2g-probe-delay=yes` (2,4-GHz-Configs) | MikroTiks *dafür gebautes* Werkzeug; verzögert nur Probe-Antworten und **kann keinen Client stranden lassen**. Adressiert die **Band-Oszillation** — ein anderes Symptom | sehr gering | 🔜 | +| 4 | `signal-range`-Boden per `access-list` (Fund E im Original) | **kann Clients aussperren** — genau das war 08-22 das Gegenargument; nur mit gemessenem Wert | hoch | 🔜 | + +#### 🔬 Hebel 1 — gezogen am 2026-08-31 08:09, Messung läuft bis 2026-09-01 + +**Was steht:** `sec-main` am Core auf **`ft=yes ft-over-ds=no`**. Abnahme **am Manager** über alle +Master-VAPs — `cap-wifi3/4/5/6` (= ap2 + ap3) melden `ft=true ft-over-ds=false`; `cap-wifi1/2` (= ap1) +sind leer, weil ap1 funkstill ist. Danach `remote-cap provision [find]`; alle drei CAPs kamen mit +`state=Ok` zurück, alle VAPs `running=yes` **am CAP gelesen**, und das iPhone hing 71 s später wieder +auf `dirtyvader-main` mit **`auth-type=ft-wpa3-psk`** und **frischer DHCP-Lease** `10.40.10.196` — +also die vorgeschriebene Abnahme (Lease, nicht Registration-Table). 30 Clients insgesamt zurück. + +**Governance:** Transaktion `TP25-fund-e-ft-over-ds` (Scope `wifi-security`, Ablauf 2026-09-03), +Geräte-Backup `pre-tp25-funde-ftoverds.backup` auf dem Core, Snapshot +[`docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc`](transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc). +Compliance danach **134/135**, und der Diff ist **exakt** `ft-over-ds=yes → no` auf `sec-main` — +kein Kollateral-Drift durch die Re-Provisionierung. Das GC-Template wird **beim Commit** nachgezogen, +nicht vorher: sonst wäre der laufende Versuch unsichtbar und `status` könnte ihn nicht mehr von einem +Versehen unterscheiden. + +🔴 **Die `cap-wifiN`-Karte hat sich durch die Re-Provisionierung VERSCHOBEN** — wer die Logs vom +31.08. auswertet, muss den Schnitt kennen, sonst ordnet er Ereignisse dem falschen AP zu: + +| | vor 08:09 (Log 07:xx) | ab 08:09 | +|---|---|---| +| ap1 (funkstill) | — | `cap-wifi1` / `cap-wifi2` | +| ap2 | `cap-wifi1` / `cap-wifi2` | `cap-wifi3` / `cap-wifi5` | +| ap3 | `cap-wifi5` / `cap-wifi6` | `cap-wifi4` / `cap-wifi6` | + +⚠️ **Korrektur am Befund: `main` unterscheidet sich in ZWEI Attributen, nicht einem.** Neben +`ft=yes ft-over-ds=yes` fährt `sec-main` als einzige SSID **`authentication-types=wpa3-psk` allein**; +die fünf anderen sind `wpa2-psk,wpa3-psk`. Die Kontrollgruppe trennt also FT **und** WPA3-only nicht +voneinander. Das ändert nichts an der Hebelreihenfolge (die Foren-Hypothese nennt genau die +Kombination WPA3+FT), aber die Formulierung „genau ein Attribut" ist zu stark — **wenn Hebel 1 und 2 +beide nichts bewegen, ist `wpa2-psk,wpa3-psk` auf `sec-main` der nächste Kandidat, nicht `signal-range`.** + +**Messung (Erfolgskriterium): `reauthenticating` für `F2:62:4C:E1:AF:09` geht auf ~0, ohne dass die +anderen SSIDs neue Ereignisse zeigen. Die Zahl MUSS sich bewegen.** + +```bash +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'" +``` + +Baseline **93** (alle iPhone, alle `main`); davon **79 am 31.08., alle in Stunde 07**, der letzte um +**07:34:43** — also **vor** dem Eingriff. Zwischen 08:00 und 08:15 kein einziges. Das ist noch **kein +Ergebnis**, nur der saubere Schnitt. *(Der Defekt war nie gegenstandslos, nur unbelegt: Fund B/C wurden am 08-20 mit ap1 auf `ether15` gemessen — also in genau der Stellung, in der ap1 heute wieder hängt. Er ist platzierungsunabhängig.)* diff --git a/docs/transaktionen/TP25-fund-e-ft-over-ds.json b/docs/transaktionen/TP25-fund-e-ft-over-ds.json new file mode 100644 index 0000000..56f4a9d --- /dev/null +++ b/docs/transaktionen/TP25-fund-e-ft-over-ds.json @@ -0,0 +1,14 @@ +{ + "change_id": "TP25-fund-e-ft-over-ds", + "device": "crs326-core", + "scope": "wifi-security", + "match_config": [ + "/interface wifi security" + ], + "reason": "TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main. Nimmt die Aenderung vom 2026-08-17 zurueck; FT bleibt over-the-air via ft=yes. Baseline 93x reauthenticating, 93/93 vom iPhone F2:62:4C:E1:AF:09, 93/93 auf dirtyvader-main (einzige SSID mit ft=yes). 24h messen, dann committen oder Hebel 2 (ft=no).", + "started": "2026-08-31", + "expires": "2026-09-03", + "state": "open", + "snapshot": "docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc", + "device_backup": "pre-tp25-funde-ftoverds.backup" +} diff --git a/docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc b/docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc new file mode 100644 index 0000000..36e6c43 --- /dev/null +++ b/docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc @@ -0,0 +1,11 @@ +# Snapshot des Scopes 'wifi-security' auf crs326-core, 2026-08-31 (Transaktion TP25-fund-e-ft-over-ds) +# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo. + +/interface wifi security +add authentication-types=wpa3-psk ft=yes ft-over-ds=yes name=sec-main +add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-infra +add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-iot +add authentication-types=wpa2-psk,wpa3-psk ft=no name=sec-media +add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=\ +sec-untrusted +add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-guest diff --git a/nautobot/gc-transaktion.py b/nautobot/gc-transaktion.py index 0248b31..a9ee500 100644 --- a/nautobot/gc-transaktion.py +++ b/nautobot/gc-transaktion.py @@ -123,10 +123,14 @@ def geheim(device): def export(device): """/export vom Geraet holen — der Snapshot, gegen den spaeter zurueckgebaut wird.""" ip = IPS.get(device) or sys.exit("Keine IP fuer %r." % device) - p = subprocess.run(["sshpass", "-p", geheim(device), "ssh", + # 🔴 `sshpass -p` schreibt das Passwort in argv, wo es in `ps` und jedem + # argv-Trace steht — genau so ist am 2026-08-22 das Core-Passwort in ein + # Transkript geraten. `-e` haelt es in der Umgebung des Kindprozesses. + umgebung = dict(os.environ, SSHPASS=geheim(device)) + p = subprocess.run(["sshpass", "-e", "ssh", "-o", "StrictHostKeyChecking=no", "-o", "ConnectTimeout=10", "admin@" + ip, "/export"], - capture_output=True, text=True, timeout=120) + capture_output=True, text=True, timeout=120, env=umgebung) if p.returncode != 0: sys.exit("Export fehlgeschlagen (rc=%d). %s" % (p.returncode, p.stderr[:200])) return p.stdout