From 2fe5bcf4cac7e4257137aaee314f3bb620c38ed0 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sat, 22 Aug 2026 23:53:45 +0200 Subject: [PATCH] Uebergabe: TP25 im Kern erledigt, TP6 ist wieder der kritische Pfad TP25 hat den Pfad seit dem 08-20 blockiert und ist im Kern durch -- die Terrasse ist repariert, Fund E abgestuft. Der TP25-Header und der Abschnitt "Kritischer Pfad" sagten beide noch das Gegenteil und sind nachgezogen. Neu: docs/handoff-20260822-naechste-schritte.md -- fuenf zugeschnittene Sessions, jede mit frischem Kontext arbeitsfaehig: 1. TP6 bauen ODER begruendet schliessen. Diese Session MISST NICHT, sie entscheidet: formal Fall B (+28..47 ms), aber durch sechs Lastphasen mit laufendem Videocall kein einziger Problem-Klick. Wenn gebaut wird, erst /queue ins GC-Template plus ComplianceRule, dann die Queue, dann A/B. 2. Admin-Passwort der vier MikroTik rotieren. Vorbedingung ist erledigt -- kein sshpass -p mehr im Repo. 3. TP25 abschliessen: Fund F messen (am MANAGER, die AP-Tabellen sind unter CAPsMAN leer) + Entscheidung 5 GHz auf 20 MHz. 4. ComplianceRule fuer /interface wifi access-list -- seit tp25-pin-s22.sh nicht mehr theoretisch. 5. Der Rest ohne Rangfolge (TP12.1 mit zwingender Reihenfolge v6-Firewall VOR Adressen, TP16.3, TP24, TP20.1, ...). Dazu eine Werkzeugtabelle, damit niemand neu baut, was schon existiert, und die drei Fallen dieser Sitzung, die wiederkommen werden: dynamische cap-wifiN-Nummern, abgewiesene Verbindungsversuche die wie Funkloecher aussehen, und dreimal Anzeige-statt-Wirkung. Co-Authored-By: Claude Opus 5 --- docs/handoff-20260822-naechste-schritte.md | 119 +++++++++++++++++++++ docs/teilprojekte.md | 12 ++- 2 files changed, 129 insertions(+), 2 deletions(-) create mode 100644 docs/handoff-20260822-naechste-schritte.md diff --git a/docs/handoff-20260822-naechste-schritte.md b/docs/handoff-20260822-naechste-schritte.md new file mode 100644 index 0000000..3256134 --- /dev/null +++ b/docs/handoff-20260822-naechste-schritte.md @@ -0,0 +1,119 @@ +# Übergabe 2026-08-22 — was als Nächstes, jeweils als eigene Session + +Jeder Block unten ist **eine Session mit frischem Kontext**. Reihenfolge = Empfehlung, nicht +Zwang; die Blöcke hängen nicht voneinander ab. Einstieg immer: `docs/teilprojekte.md` lesen. + +--- + +## 1️⃣ TP6 — CAKE bauen **oder begründet schließen** (das eigentliche Projektziel) + +**Warum jetzt:** TP25 hat den kritischen Pfad seit dem 08-20 blockiert und ist erledigt. TP6 ist +damit der einzige verbliebene Punkt — und das Ziel, mit dem dieses Projekt angefangen hat. + +🔴 **Diese Session misst NICHT neu. Sie entscheidet.** Die Prämisse ist am 08-20/21 geprüft +([`tp6-praemisse-messrunbook.md`](tp6-praemisse-messrunbook.md) §5): + +| | idle | Upload-Last | Download-Last | +|---|---|---|---| +| gemessen | 12,9 ms | **60,4 ms** | 41,3 ms | +| Referenz 06-16 | 12 ms | 17,5 ms | — | + +Linerate 9,6 Mbit up / 54,6 Mbit down. Der Anstieg liegt bei **+28 bis +47 ms** in der +Senderichtung und damit über der §3-Schwelle → **formal Fall B, CAKE ist begründet.** +🔴 **Aber:** durch alle sechs Lastphasen lief ein Telegram-Videocall, und es wurde **kein +einziger Problem-Button gedrückt**. waveform gab zeitgleich Grade A. + +**Die zu beantwortende Frage ist also nicht „ist es messbar", sondern „lohnt es".** +Argumente für Bauen: 9,6 Mbit Upload ist wenig, ein einzelner Upload sättigt sie; Bufferbloat +trifft dann alles andere. Argumente für Schließen: nicht wahrnehmbar, und jede Queue ist +dauerhafte Komplexität in einem Pfad, der heute funktioniert. + +**Wenn gebaut wird, Reihenfolge zwingend** (§4.1): erst `/queue` ins GC-Template **plus** +ComplianceRule, dann die Queue deployen, dann dieselbe Messung als A/B-Nachweis. Nicht am Gerät +vorbei — `project_ap_config_freeze_until_nautobot`. + +**Wenn geschlossen wird:** in `teilprojekte.md` als „gemessen, bewusst nicht gebaut" mit den +Zahlen dokumentieren. Dann ist der kritische Pfad **leer** und Christoph setzt das nächste Ziel. + +--- + +## 2️⃣ Admin-Passwort der vier MikroTik rotieren + +**Warum:** das Core-Passwort ist am 2026-08-22 durch eine Debug-Ausgabe im Klartext in ein +Sitzungstranskript geraten. Ursache war `sshpass -p`, das es in die Kommandozeile schreibt. + +✅ **Vorbedingung ist erledigt:** alle Werkzeuge laufen auf `sshpass -e` +(`tp6-monitor-core.sh`, `tp25-walk-messung.sh`, `tp25-pin-s22.sh`, `tp6-marker/server.py`). +`grep -rn "sshpass -p" docs/ nautobot/` findet nur noch die Erwähnung in der Doku. + +**Weg:** `manage_user set-password` über MikroMCP (⚠️ `/user set*` ist per Deny-Policy blockiert), +für **alle vier** Geräte — es ist ein gemeinsames Passwort („Überlebensversicherung"). Danach +nachziehen: `~/.secrets/credentials.env` (`ROUTER_*_PASS`, `CRS326_*_PASS`), `~/.claude.json`. +**Abnahme:** je Gerät ein Lesezugriff mit dem neuen Passwort — nicht die Anzeige des Jobs. + +--- + +## 3️⃣ TP25 abschließen: Fund F messen + 20-MHz-Entscheidung + +Zwei Reste, beide klein. + +**Fund F — IoT-Clients trennen exakt alle ~5:05.** Nie gemessen, nur beobachtet. +🔴 Unter CAPsMAN ist die Registration-Table **am Manager** zu lesen, die AP-Tabellen sind leer +(`ref_capsman_slaves_datapath`). Werkzeug: `docs/tp6-monitor-core.sh --mac `, dazu +`/log print where message~""` am Core. Verdacht: DHCP-Lease-Zeit oder ein Sleepy-End-Device- +Intervall — vor der Diagnose die Lease-Zeit des VLAN30-Servers prüfen. + +**5 GHz auf 20 MHz (+3 dB):** die letzte offene Funkmaßnahme. Der Lauf vom 08-22 zeigt: die +**Alltagsabdeckung braucht sie nicht** (17 von 21 Abschnitten 0 % Verlust). Sie würde die dünne +**Rückfallebene** stärken (Schlafzimmer −85, Bad −82, Küche −82 auf dem Gegen-AP). Kosten: +Durchsatz, der laut TP6-Messung nicht knapp ist. **Entscheidung, keine Messung.** +Danach kann TP25 geschlossen werden. + +⚠️ **Fund E (`signal-range`-Boden) NICHT umsetzen**, bevor ein Sticky-Fall erneut gemessen ist — +am 08-22 reproduzierte er sich nicht (Treppe: sauberer Wechsel, 0 % über 57 s). + +--- + +## 4️⃣ Governance-Lücke: ComplianceRule für `/interface wifi access-list` + +**Warum:** es gibt Regeln für `wifi-configuration/-datapath/-security/-steering/-provisioning/ +-channel/-cap/-capsman`, aber **keine** für `access-list`. Änderungen dort erzeugen **keinen +Drift** und lassen sich nicht als Transaktion führen (`gc-transaktion.py` verlangt eine +ComplianceRule als `--scope`). + +Das ist seit dem 08-22 nicht mehr theoretisch: `docs/tp25-pin-s22.sh` schreibt bei jedem Rundgang +access-list-Regeln, und Fund E würde dort dauerhaft landen. **Aufwand: klein** (Feature + Rule +anlegen, Template ergänzen, `gc-configplan.py --refresh-compliance`). + +--- + +## 5️⃣ Danach, ohne Rangfolge + +- **TP12.1** — IPv6/ULA + v6-Firewall. 🔴 Reihenfolge zwingend: **v6-Firewall nachbauen, DANN + Adressen vergeben**, sonst steht IOT→MAIN an TP5 vorbei offen. Blockiert nur neue Thread-Geräte; + bis dahin ist die `-infra`-SSID der Standardweg (User-Entscheid: kein ESP32). +- **TP16.3** — cloudflared-Reduktion, Runbook liegt (`tp16.3-nautobot-mesh-only-runbook.md`). +- **TP24** — DC-USV · **TP20.1** — Vaultwarden→PG · **TP18** — Garage · **TP16.2** — Härtung +- **TP14.4** — CF-Access-Token · **TP13** — Botschafts-WLANs (fun) · **TP29** — Anwesenheitserkennung + +--- + +## Werkzeugstand (damit niemand neu baut, was existiert) + +| Werkzeug | was es tut | +|---|---| +| `docs/tp25-runde.sh [name]` | kompletter Messlauf: Konsole + beide Pings + AP-Karte einfrieren, räumt beim Beenden auf | +| `docs/tp6-marker/server.py` | Klick-Konsole (Port 3031, 0.0.0.0), Raumkacheln, AP-Pin, Gegen-AP-Automatik, Ton, **Stopp-Knopf** | +| `docs/tp25-pin-s22.sh {ap1\|ap2\|off\|status\|map\|which}` | Client per access-list auf einen AP festnageln; `map` liest die AP-Zuordnung **live** | +| `docs/tp25-gehweg-auswertung.py --dir ` | Raumtabelle, **beide Rollen nebeneinander** | +| `nautobot/gc-transaktion.py` | Teständerungen als Transaktion (begin/status/commit/rollback) | +| `nautobot/gc-configplan.py` | der **einzige** legitime Config-Weg für Netzgeräte | + +🔴 **Drei Fallen, die in dieser Sitzung Zeit gekostet haben und wiederkommen werden:** +1. **`cap-wifiN`-Nummern sind dynamisch** — nie hartkodieren, nie live auf alte Daten anwenden. + Die Karte gehört zum Messlauf (`ap-map.txt`). +2. **Ein abgewiesener Verbindungsversuch sieht aus wie ein Funkloch** und steht in keinem Log. + Bei gepinnten Messungen immer prüfen, wie viele Funkproben „absent" sind (08-22: 2,8 %, also + sauber). +3. **Anzeige ≠ Wirkung.** In dieser Sitzung dreimal: „beide angemeldet, verschiedene APs" bei + gleichem AP · „AP-Pin gelöst" bei stehenden Regeln · „Ruhezustand" bei eigenem Pin-Wechsel. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 7114dd9..a3da90f 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -1299,7 +1299,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **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 ▸ 🔴 **JETZT KRITISCHER PFAD — Roaming gemessen (08-20), Übergabekosten gemessen (08-21): Dead Spot statt Roaming-Problem** — Sammel-TP für Christophs Beobachtungen 1–6 +### TP25 — WLAN-Stabilisierung ▸ 🟢 **KERN ERLEDIGT (2026-08-22): Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). Offen nur noch **Fund F** (5:05-Takt IoT) und die Entscheidung **5 GHz auf 20 MHz**. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6 > 🆕 **Messung 2026-08-20/21: [`tp25-wlan-roaming-messung-20260820.md`](tp25-wlan-roaming-messung-20260820.md)** > (Nebenprodukt der TP6-Messreihen, Core-Sampler im 2-s-Takt über 2,5 h, teils mit laufendem Videocall). > Drei Befunde: @@ -1926,13 +1926,21 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ## Reihenfolge / Abhängigkeiten -### 🎯 Kritischer Pfad (Stand 2026-08-19) +### 🎯 Kritischer Pfad (Stand 2026-08-22) ``` TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 input+MGMT ✅ ─► E5 MAIN→IOT ✅ ─► TP6 (CAKE) ◄ Ziel ▲ ab hier ist alles frei ``` +> ➡️ **Update 2026-08-22 (Sitzungsende):** TP25 hat den Pfad seit dem 08-20 blockiert und ist im +> Kern **erledigt** — die Terrasse ist repariert, der Dead Spot weg, Fund E abgestuft. Damit ist +> **TP6 wieder der einzige Punkt auf dem kritischen Pfad**, und seine Prämisse ist inzwischen +> gemessen (`tp6-praemisse-messrunbook.md` §5): **formal Fall B** (+28…47 ms in der Senderichtung), +> **aber durch sechs Lastphasen mit laufendem Videocall kein einziger Problem-Klick.** Die +> nächste Sitzung entscheidet daher **bauen oder begründet schließen** — sie misst nicht neu. +> Übergabe mit den Sitzungszuschnitten: [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md). + **TP5 ist am 2026-08-18 abgeschlossen.** Damit steht rechnerisch nur noch **TP6** auf dem kritischen Pfad — 🟠 **aber dessen Prämisse ist offen**: eine Messung von 2026-06-16 (`docs/call-quality-diagnosis.md`) bescheinigt dem Netz bereits **A/A+** und hält CAKE für „marginal". Der nächste Schritt ist deshalb ein