6.6 KiB
Ü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 §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 <IoT-MAC>, dazu
/log print where message~"<MAC>" 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 <lauf> |
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:
cap-wifiN-Nummern sind dynamisch — nie hartkodieren, nie live auf alte Daten anwenden. Die Karte gehört zum Messlauf (ap-map.txt).- 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).
- 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.