From 5fd8d4edb1189f8330f17e8cea227fa040a27605 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 17 Aug 2026 18:41:57 +0200 Subject: [PATCH] TP28 dokumentiert: CAPsMAN-Cutover durch, zwei Messfallen festgehalten MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Der Cutover ist durch (34 Clients, iot=27, beide CAPs Ok, Roaming belegt). Festgehalten sind vor allem die zwei Fallen, die mich Zeit und Christoph das halbe IoT-Netz gekostet haben: 1. Unter CAPsMAN fuehrt der MANAGER die registration-table und die wireless-Logs, nicht der CAP. Auf ap1/ap2 sind beide leer, obwohl das WLAN laeuft — ich habe daraus zweimal faelschlich 'WLAN ist unten' geschlossen. 2. Drei uebereinstimmende .rsc-Dateien sind nicht drei Belege, wenn sie aus demselben Bring-up stammen. Genau daran habe ich wlan-psks.env fuer veraltet gehalten und ueberschrieben. Die Passphrasen sind am Geraet per REST lesbar — das ist der Weg, nicht der Dateivergleich. Offen: das GC-Modell beschreibt weiter Standalone-APs; die 76/76 ist stale (13:55 gemessen, Cutover 18:05). wifi-*-Features muessen auf den Core. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 1bcae0d..cf08d29 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -1184,6 +1184,50 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine explizite `forward`-Zeile — s. TP5 Etappe 2. +### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **CUTOVER DURCH (2026-08-17)** — beide APs sind reine CAPs +> **Methodenwechsel auf Christophs Anstoß:** *„ich möchte die methode in frage stellen … eine sot ist zwar nett, +> aber wenn sie uns das leben zur hölle macht, verzichte ich auf diese governance."* Der Entscheid vom +> 2026-07-22, CAPsMAN abzuschaffen, ist damit **revidiert**. + +- ✅ **Warum es diesmal trägt:** 2026-07-22 war **ap1 Manager UND AP** — und ein Manager kann seine eigenen + Radios nicht per CAPsMAN provisionieren (MikroTik-bestätigt). Genau diese Asymmetrie war die Ursache von + TP3.1. Mit dem **Core** als Manager sind beide APs symmetrisch. **Der Core braucht dafür kein `wifi-qcom`:** + das `capsman`-Menü steckt im Basis-`routeros`, die 3,35 MB freier Flash sind irrelevant. Die zweite + Begründung von damals („WLAN instabil") war ohnehin widerlegt — standalone blieb es instabil, die Ursachen + waren die Funkparameter aus TP25. +- ✅ **Ist-Stand:** Manager auf `vlan99`, 4 Kanäle · 6 Datapaths · 6 Security · 2 Steering · 9 Configurations · + 4 Provisioning-Regeln je `radio-mac`. Beide `remote-cap` **`Ok`**, je 7 dynamische VAPs. Kanäle exakt wie in + TP25 gemessen (ap1 `5180/ax/Ce/I`+`2412/ax`, ap2 `5220/ax/Ce/I`+`2462/ax`). **34 Clients** (main 3, iot 27, + media 4), Roaming im Manager-Log belegt. **`ft-over-ds=yes`** ist jetzt aktiv (unter CAPsMAN erstmals + verfügbar), `-guest` hat eigenes `st-guest` mit **`neighbor-group=bf-guest`** — nicht `bf-main` mitbenutzen, + sonst meldet 802.11k Gast-Clients BSSIDs einer SSID, auf die sie nicht assoziieren können. +- 📌 **Local-Forwarding ist keine Einstellung mehr:** im neuen `/interface/wifi` gibt es **kein** zentrales + Forwarding („There is no CAPsMAN-forwarding in WiFi (RouterOS 7.0+)"). Die `datapath`-Property existiert + deshalb nicht — `monitor` bestätigt `traffic processing on CAP`. +- 🔴 **DIE MESSFALLE DIESES TPs — unter CAPsMAN führt der MANAGER die Tabellen, nicht der CAP.** + `/interface/wifi/registration-table` und die `wireless`-Logs sind auf ap1/ap2 **leer**, obwohl das WLAN + einwandfrei läuft. Ich habe daraus zweimal „WLAN ist unten" geschlossen, während Christophs Geräte mit + vollem Ausschlag verbunden waren und ein Speedtest gut lief. **Immer am Manager zählen.** +- 🔴 **DIE ZWEITE FALLE — drei übereinstimmende Dateien sind nicht drei Belege.** `wlan-psks.env` wich für + iot/untrusted/infra von `ap1-prov-base.rsc`, `ap2-prov-base.rsc` und `ap1-standalone.rsc` ab. Ich habe die + drei als Bestätigung gelesen und die env-Datei „korrigiert" — **~20 Shellys waren 20 Minuten aus dem Netz.** + Die drei Dateien stammen alle aus dem Bring-up vom 2026-08-08, sind also **eine Quelle in drei Kopien**. + ✅ **Auflösung:** die Passphrasen sind am Gerät per REST **lesbar** + (`GET http://10.40.99.1/rest/interface/wifi/security`) — dort ausgelesen ergab sich exakt der env-Wert. + `wlan-psks.env` ist neu aus dem Live-Stand befüllt und trägt jetzt eine Kopf-Warnung; die drei Baselines + sind seit dem Cutover ohnehin nicht mehr deploybar und wurden entschärft (Passphrasen raus, HISTORISCH). +- ⚠️ **OFFEN — das GC-Modell beschreibt weiter Standalone-APs.** Compliance meldet `76/76`, die Zahl ist aber + **stale**: sie lief um 13:55, der Cutover war um 18:05, und ap1s intended config trägt noch 22 + `/interface wifi`-Zeilen. Nach dem nächsten Refresh driften ap1/ap2 auf allen fünf `wifi-*`-Features. + **Nächster Schritt:** die `wifi-*`-Features vom AP-Scope auf den Core umhängen, AP-Template auf die + Mini-Config (bridge/VLAN/Mgmt/`cap enabled`) eindampfen. Damit wird auch die bisher fehlende Rule auf + `/interface wifi` **gegenstandslos** — ein CAP hat keine Inline-Overrides, die driften könnten. +- 📌 **Nebenbefund:** HAs `mikrotik`-Integration pollt alle 10 s und schreibt zwei Log-Zeilen pro Poll auf jedes + Gerät. Die AP-Logs sind dadurch für Diagnose praktisch unbrauchbar (`get_log` ohne `topics`-Filter liefert + nur `admin logged in/out via api`). +- **Abh.:** TP25 ✅ (die Funkparameter sind übernommen), TP15/TP21.1 ✅ (Core als L3-Router = Manager-Standort). + Verwandt: **TP3** (dessen CAPsMAN-Ära hier revidiert wird), **TP22** (GC-Scope). + ### TP-R — Router-Capabilities-Sweep ▸ FERTIG (`docs/research/routeros-capabilities.md`) - **Leitsatz: nativ vor Container, NAS vor Router** (128MB-Flash-Limit). - **Sofort nativ (~0 RAM):** RoMON · Netwatch · Scheduler + Auto-Backup/Mail · SNMP→externes Monitoring · **mDNS-Repeater** · spectral-scan · **802.11r/k/v (Fast-Roaming statt Mesh)** *(die Sweep-Fassung nannte hier CAPsMAN — das ist seit 2026-08-08 abgeschafft; 11r/k/v läuft standalone weiter, s. TP3/TP3.3)* · Back-to-Home/WireGuard.