From d4221016c642dad0d21aa2b8779e163062961061 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 15:08:45 +0200 Subject: [PATCH] Session 2026-08-23 uebergabebereit + access-list von Grund auf erklaert Uebergabe docs/handoff-20260823-session.md: was die Session war (Doku-Split Punkt F fertig, dann Shelly-/Funkmigration), womit die naechste anfangen sollte (TP17.3 -- einziger offener Punkt mit spuerbarem Alltagsschaden, von uns verursacht, blockiert TP17.1), und die Zahlen, die niemand neu erheben muss. Neu: docs/wifi-access-list-erklaert.md auf Christophs Wunsch ("keine ahnung von tuten und blasen"). Von Null: was die Liste ist, wo sie unter CAPsMAN lebt, wann sie greift, was eine Regel matchen kann -- und der eine Satz, der alle Ueberraschungen erklaert: eine Regel kann nur nein sagen, sie kann kein Geraet irgendwo hinschicken. Dazu die drei Anwendungsfaelle im Projekt (Signal-Boden, Messen, PSK-Wechsel ohne Flag-Day), die Governance seit der ComplianceRule und fuenf Merkregeln aus echten Fehlgriffen. Ausserdem: ein Duplikat von TP17.3 entfernt, das ich beim Anlegen uebersehen hatte -- der Abschnitt existierte bereits und war deutlich gruendlicher (Phasenanschnitt- Hypothese, Gegenprobe s12, stale eco-Politik, restart_required-Fund). Die ausfuehrliche Fassung bleibt. Co-Authored-By: Claude Opus 5 --- docs/handoff-20260823-session.md | 89 ++++++++++++++++++++++++++++++ docs/wifi-access-list-erklaert.md | 92 +++++++++++++++++++++++++++++++ 2 files changed, 181 insertions(+) create mode 100644 docs/handoff-20260823-session.md create mode 100644 docs/wifi-access-list-erklaert.md diff --git a/docs/handoff-20260823-session.md b/docs/handoff-20260823-session.md new file mode 100644 index 0000000..19a6aef --- /dev/null +++ b/docs/handoff-20260823-session.md @@ -0,0 +1,89 @@ +# Übergabe — Session 2026-08-23 + +> **Einstieg für die nächste Session:** diese Datei, dann [`teilprojekte.md`](teilprojekte.md). +> **Zustand am Netz: unverändert.** Alles, was angefasst wurde, ist zurückgerollt; keine offenen +> Transaktionen auf `crs326-core`, `access-list` leer, PV liefert. + +## Was diese Session war — und was sie wurde + +Begonnen als **Doku-Session (Punkt F: `teilprojekte.md` aufteilen)**. Das ist **fertig**. Danach hat +Christoph den Faden zur Shelly-/Funkmigration aufgemacht, und daraus wurde der größere Teil des Tages. + +| | | +|---|---| +| ✅ **Doku-Split** | 2217 → 790 Zeilen Hauptdatei + [`teilprojekte-archiv.md`](teilprojekte-archiv.md) (34 abgeschlossene TPs). **Damit ist `doku-cleanup-session.md` A–F komplett** — die Akte kann zu. | +| ✅ **TP17.1 aktiviert** | Shelly Gen4 raus aus dem WLAN. Entscheidungsreif, nicht gestartet — [Runbook](tp17.1-shelly-gen4-funkmigration-runbook.md). | +| ✅ **TP17.3 angelegt** | Die Shelly-Regression (Blinken/Doppelklick). **Leithypothese steht, Test ist formuliert.** | +| ✅ **Funkbild erhoben** | Alle 2,4-GHz-Netze vermessen, Nachbarschaft gescannt. | +| ✅ **DTU vollständig geklärt** | Inkl. eines Fehlschlags mit 10 min PV-Ausfall — s.u. | +| ✅ **PSK-Entscheid** | Rotation bleibt, wird **nach** TP17.1 gemacht. Historie bleibt, kein filter-repo. | + +## 🔴 Womit die nächste Session anfangen sollte + +**TP17.3 — die Shelly-Regression.** Es ist der einzige offene Punkt mit **spürbarem Alltagsschaden**, +er ist **von uns verursacht**, und er **blockiert TP17.1** (an Geräten, die spinnen, fängt man keine +Funkmigration an). Der diskriminierende Test steht fertig im TP: `eco_mode` auf `s23` abschalten, AP +zunächst an lassen, dann AP aus. Klein, reversibel, ein Gerät. + +⚠️ **Vorher lesen, nicht überspringen:** der aktivierte AP auf `s23` ist **Christophs Workaround**, +kein Rückstand. Ich hatte ihn am selben Tag fälschlich als „vergessenen Anker" gemeldet. **Nicht +abschalten, bevor die Ursache behoben ist.** + +## Danach, ohne Rangfolge + +- **5-GHz-Umfeldscan**, bevor die **zwei neuen APs** eingebaut werden — 2,4 GHz ist vermessen, 5 GHz + nicht, und dort werden die neuen APs geplant. DFS ist von Christoph freigegeben. +- **Anker-Sweep über alle Shellys** (`WiFi.GetConfig` → `ap.enable`): bei `s23` ist ein AP an, die + übrigen 21 sind **nie gegengeprüft** worden. Read-only, eine Minute. *(Ergebnis mit TP17.3 abgleichen + — ein aktiver AP kann ein Workaround sein.)* +- **TP17.1 Schritt 0**: die Entscheidung Zigbee (heute verfügbar, Hersteller-Firmware) vs. Thread + (Dritt-Firmware, Garantie weg) vs. warten. Gehört Christoph, nicht dem Umsetzenden. +- **TP25 Fund F** (5:05-Takt bei IoT) und die Entscheidung **5 GHz auf 20 MHz**. +- **PSK-Rotation** — nachgelagert hinter TP17.1, Vorarbeit steht im Follow-up. + +## Der Fehlschlag des Tages, damit ihn niemand wiederholt + +**Auftrag:** den nicht abschaltbaren DTU-AP von ch1 wegbekommen, indem der Client per `access-list` an +ap2 gebunden wird. **Ergebnis:** der Wechselrichter flog von ap1, kam bei ap2 **nie** an, und auch nach +dem Rollback nicht zurück — **10 Minuten ohne PV-Telemetrie**, behoben erst durch Christophs +Re-Provisionierung über die S-Miles-App. + +Die Auflösung kam aus dem Gerät selbst (`get-config` über Port 10081, read-only): +**`channel_select = 0`** — es gibt **keine** feste Kanalwahl. **Nicht der Kanal ist starr, sondern die +AP-Bindung:** das Gerät sucht keinen anderen AP, es gibt auf. + +Drei Merkregeln daraus, alle jetzt in [`wifi-access-list-erklaert.md`](wifi-access-list-erklaert.md): +1. **`reject` ist kein Umzug, sondern ein Rausschmiss.** Wohin das Gerät geht, entscheidet das Gerät. +2. **Signalstärke ist kein Nachweis für Assoziationsfähigkeit.** +3. **Für den PV-Wechselrichter ist die `access-list` gesperrtes Gebiet** — ein `reject` kostet dort + einen Vor-Ort-Einsatz. + +✅ **Was dabei trotzdem gewonnen wurde:** ap1s Kanal umzulegen **würde** wirken — der DTU folgt, ohne +je abgewiesen zu werden. Das ist der risikoarme Weg und fällt beim Kanalplan für die neuen APs an. + +## Zahlen, die man nicht neu erheben muss + +**Funkbild 2,4 GHz** (alles live am 2026-08-23): + +| Netz | Kanal | Geräte | +|---|---|---| +| WLAN ap1 / ap2 | **1** / **11** | 26 der 27 Clients hängen auf `dirtyvader-iot` | +| Thread (OTBR) | **15** | ~30 Matter-Knoten | +| ZHA | **20** | **52** Geräte, SONOFF Dongle-M über `socket://10.40.30.137:6638` | +| Z2M (`z2m25`) | **25** | 15 Geräte, Sonoff Dongle Plus | +| Homematic/HmIP | **868 MHz** | 37 Geräte — außerhalb dieser Rechnung | + +- **Nachbarschaft ist leise:** kein Fremdnetz über −81 dBm. Die lautesten Störer sind die eigenen — + der DTU-AP (ch1, −59) und der Shelly-`s23`-AP (ch11, −51). +- **ZHA ch20 grenzt an WLAN ch11**, aber `PHY_CCA_FAIL_COUNT = 4` sagt: es beißt nicht. **ZHA bleibt + auf 20.** Ein Wechsel auf 18 wäre valide, hat aber keinen Anlass — und **müsste von 52 Geräten + mitgemacht werden**. +- **Shelly-Bestand:** 22 von 26 erreichbar — **12 Gen4**, 8 Gen3, 2 Gen2, alle Firmware `2.0.0`. + Nur `s4 kueche_mikrowelle` ist offline (RSSI −93 hinter Metall). +- **Compliance:** 104/104, 0 Drifts, 26 Rules × 4 Geräte (live geprüft). + +## Neue Dokumente aus dieser Session + +- [`teilprojekte-archiv.md`](teilprojekte-archiv.md) — 34 abgeschlossene TPs +- [`tp17.1-shelly-gen4-funkmigration-runbook.md`](tp17.1-shelly-gen4-funkmigration-runbook.md) — Bestand, Firmware-Lage, Funkbild, UART, DTU +- [`wifi-access-list-erklaert.md`](wifi-access-list-erklaert.md) — **von Grund auf**, auf Christophs Wunsch diff --git a/docs/wifi-access-list-erklaert.md b/docs/wifi-access-list-erklaert.md new file mode 100644 index 0000000..ed316ec --- /dev/null +++ b/docs/wifi-access-list-erklaert.md @@ -0,0 +1,92 @@ +# Die WLAN-`access-list` — von Grund auf erklärt + +> **Warum es dieses Dokument gibt:** die `access-list` taucht in diesem Projekt an drei Stellen auf +> (TP25 Fund E, der Mess-Pin `tp25-pin-s22.sh`, der gescheiterte DTU-Versuch vom 2026-08-23) — und sie +> ist genau das Werkzeug, mit dem man sich still ins Knie schießt, wenn man ihr Wesen nicht kennt. +> Stand 2026-08-23. + +## In einem Satz + +Die `access-list` ist eine **Türsteher-Liste am WLAN**: für jeden Client, der sich anmelden will, geht +sie von oben nach unten durch und entscheidet **ja oder nein** — pro AP, pro Funkschnittstelle, pro +Gerät. + +## Wo sie lebt + +`/interface wifi access-list` — und bei uns **auf dem Manager `crs326-core`**, nicht auf den APs. +Unter CAPsMAN besitzen ap1/ap2 ihre Radios nicht; sie fragen den Manager. *(Dieselbe Regel wie bei der +Registration-Table: der Manager führt die Tabellen.)* + +## Der eine Satz, den man wirklich verstehen muss + +> 🔴 **Eine `access-list`-Regel kann einem Gerät nur „nein" sagen. Sie kann es nicht irgendwo +> hinschicken.** + +Das klingt trivial und ist die Quelle fast aller Überraschungen. Wer einen Client „auf ap2 umziehen" +will, verbietet ihm in Wahrheit **ap1** — und hofft, dass er von selbst zu ap2 geht. Ob er das tut, +entscheidet **das Gerät**, nicht der Router: + +| Gerätetyp | Reaktion auf ein `reject` | +|---|---| +| Telefon, Laptop | sucht sofort einen anderen AP → der Umzug klappt | +| einfaches IoT-Gerät | hängt am gespeicherten AP fest, versucht es weiter — **oder gibt ganz auf** | + +**Am 2026-08-23 live erlebt:** der PV-Wechselrichter wurde auf ap1 abgewiesen, ging **nicht** zu ap2, +und kam auch nach dem Entfernen der Sperre nicht zurück. Er musste über die Hersteller-App neu +provisioniert werden. Zehn Minuten Ausfall der PV-Telemetrie. **Ein „nein" an ein Gerät ohne +Suchlogik ist ein Abschalten.** + +## Wann sie greift + +**Nur im Moment der Anmeldung** (Association) — nicht laufend. Zwei Folgen: +- Eine neue Regel wirft bestehende Verbindungen **nicht automatisch** raus … *außer* RouterOS wertet + sie neu aus, was es bei Änderungen an der Liste tut: im Log steht dann + `disconnected, access-list changed`. +- Wer eine Regel testet, muss den Client **einmal trennen**, sonst misst er den alten Zustand. + +## Was eine Regel matchen kann + +| Feld | Bedeutung | +|---|---| +| `mac-address` | genau ein Gerät | +| `interface` | ein bestimmtes Radio bzw. eine bestimmte SSID (bei uns `cap-wifiN` / `cap-wifiN-virtualM`) | +| `signal-range` | **nur Clients innerhalb dieses dBm-Fensters** — das Werkzeug gegen klebende Clients | +| `time` | Uhrzeit/Wochentag | + +Und als Aktion im Kern: **`accept`** oder **`reject`**. Dazu kommt eine Besonderheit, die +kein Verbot ist, sondern eine Ausnahme: eine Regel kann einem einzelnen Gerät ein **eigenes +WLAN-Passwort** zuweisen (`passphrase`) — der Trick, mit dem sich ein PSK-Wechsel ohne Stichtag machen +lässt (neues Passwort aufs Profil, Altgeräte übergangsweise per MAC mit dem alten weiter). + +## Die drei Dinge, für die wir sie brauchen + +1. **Signal-Boden gegen klebende Clients** (TP25 „Fund E"). Ein Client, der bei −85 dBm an einem + fernen AP klebt, obwohl zwei Meter weiter ein besserer steht, wird mit einem `signal-range`-Fenster + frühzeitig abgewiesen — er sucht sich dann den stärkeren. ⚠️ **Wirkt nur, wenn es einen besseren AP + gibt.** Auf der Terrasse gab es keinen; dort hätte ein Boden die Lage *verschlechtert*. +2. **Messen** (`tp25-pin-s22.sh`): ein Testgerät gezielt auf **einen** AP zwingen, um den Gegen-AP zu + vermessen. Genau hierfür ist sie gebaut — Testgeräte haben Suchlogik. +3. **PSK-Wechsel ohne Flag-Day** (s. `passphrase` oben) — vorgemerkt für die Rotation. + +## Governance in diesem Projekt + +Seit **2026-08-23** steht `/interface wifi access-list` unter der ComplianceRule `wifi-access-list`. +Das heißt: **jeder Eintrag erzeugt Drift** und gehört als Transaktion geführt +(`nautobot/gc-transaktion.py begin …`), sonst sieht ein Versuch aus wie ein Versehen. +Der Soll-Zustand ist **leer**. + +## Merkregeln, jede aus einem echten Fehlgriff + +- 🔴 **`reject` ist kein Umzug, sondern ein Rausschmiss.** Vorher fragen: *kann und will dieses Gerät + woanders hin?* +- 🔴 **Signalstärke ist kein Nachweis für Assoziationsfähigkeit.** „Der andere AP hört ihn mit −59 dBm" + belegt einen Funkpfad — nicht, dass das Gerät dort hingeht. +- 🔴 **Ein abgewiesener Verbindungsversuch ist in Ping-Daten nicht von einem Funkloch zu + unterscheiden**, und der Manager protokolliert ihn auf `info`-Ebene **gar nicht**. Wer mit einem Pin + misst, braucht eine eigene Alarmierung für „Gerät hängt nirgends". +- 🔴 **Die `cap-wifiN`-Nummern sind nicht stabil** — sie werden in der Reihenfolge vergeben, in der + sich die CAPs anmelden. Eine Regel, die auf `cap-wifi4` zeigt, kann nach einem AP-Neustart ein + anderes Radio meinen. **Vor jedem Eingriff die Zuordnung über `radio-mac` neu bestimmen.** + ⚠️ Besonders relevant, sobald die zwei neuen APs dazukommen: dann wird neu durchnummeriert. +- ⚠️ **Für den PV-Wechselrichter ist die Liste gesperrtes Gebiet** — nicht wegen des Kanals, sondern + weil er nach einem `reject` aufgibt und einen Vor-Ort-Einsatz braucht.