diff --git a/docs/doku-cleanup-session.md b/docs/doku-cleanup-session.md index e4c2e79..6c7eb5c 100644 --- a/docs/doku-cleanup-session.md +++ b/docs/doku-cleanup-session.md @@ -128,7 +128,10 @@ Grobschätzung: A+B+C ≈ eine Session, D+E ≈ eine halbe. ## Abnahme 1. Eine frische Session liest **nur** `docs/teilprojekte.md` und beschreibt daraus die Topologie korrekt: - `crs326-core` als L3-Router, kein sw1/sw2, kein Omada, kein CAPsMAN, ap1/ap2 als APs. + `crs326-core` als L3-Router **und CAPsMAN-Manager**, kein sw1/sw2, kein Omada, ap1/ap2 als **reine CAPs**. + ⚠️ **Korrigiert am 2026-08-19:** hier stand bis dahin „kein CAPsMAN" — als *Abnahmekriterium*. + Ein Kriterium, das den falschen Zielzustand beschreibt, macht jede Prüfung wertlos; es hätte eine + Session bestätigt, die den überholten Stand wiedergibt. Seit TP28 (2026-08-17) ist CAPsMAN zurück. 2. `grep -n "CAPsMAN\|Omada\|ap1.*Router" docs/teilprojekte.md` — jeder Treffer ist entweder als Historie markiert oder korrekt. 3. Der ⚠️-Provisorium-Vorspann über Zeile 21 ist **weg** (weil überflüssig geworden). diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 6b01b1c..5b1578a 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -132,8 +132,18 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na - **Offen/nachzuziehen (nicht blockierend):** finale Portbelegung + IP von sw2 in `docs/ip-plan.md`/CLAUDE.md-Hardware-Tabelle nachtragen (aktuell dort noch „Adoption pending" — stale, aber Wert unbekannt, nicht geraten); `omada/.secrets` auf neue Standalone-Creds prüfen; ob Omada-Controller-Container jetzt komplett überflüssig ist. - Abh.: TP1 ✅ (VLAN-Trunk am Uplink). Verwandt: TP15 (löst sw2 mittelfristig durch CRS326 ab), TP14.1 (Auslöser). -### TP3 — WLAN (Standalone-APs) ▸ ✅ **REBUILD DURCH (2026-08-08): beide hAP ax² sind reine Standalone-APs, CAPsMAN abgeschafft** — Erstaufbau ✅ 2026-06-18 (`routeros/tp3-capsman.rsc` = **historisch**, aktuelle Configs `routeros/.secrets/ap{1,2}-prov-base.rsc`) -> ⚠️ **Lesehinweis:** die folgenden Punkte bis zum ✅-DURCH-Eintrag am Ende beschreiben die **CAPsMAN-Ära (Juni/Juli 2026)** und sind bewusst als Historie erhalten — der Ist-Stand steht im letzten Punkt dieses TPs. +### TP3 — WLAN ▸ 📜 **VOLLSTÄNDIG HISTORISCH — der Ist-Stand steht in TP28, nicht hier** +> 🔴 **Lesehinweis (überarbeitet 2026-08-19): dieser gesamte TP ist Geschichte, von der ersten bis zur +> letzten Zeile.** Er beschreibt zwei überholte Zustände nacheinander — die **CAPsMAN-Ära (Juni/Juli +> 2026)** und danach den **Standalone-Rebuild vom 2026-08-08**. Beides gilt nicht mehr: +> seit **TP28 (2026-08-17)** läuft das WLAN wieder über **CAPsMAN, mit `crs326-core` als Manager**; +> ap1/ap2 sind reine CAPs ohne eigene WLAN-Konfiguration. +> +> ⚠️ **Bis 2026-08-19 trug dieser TP im Header „beide hAP ax² sind reine Standalone-APs, CAPsMAN +> abgeschafft" und der Lesehinweis verwies als „Ist-Stand" auf den 08-08-Eintrag.** Wer die WLAN-Frage +> hatte, landete zuerst hier — und bekam die falsche Antwort. Genau daran ist eine frische Session am +> 2026-08-19 hängengeblieben. **Für den aktuellen WLAN-Stand: TP28 lesen, für Funkparameter TP25.** +> Der Wert dieses TPs sind die Gotchas (VLAN-Leck ohne `datapath`, Bring-up-Fallen), nicht der Status. - ✅ **5 sichtbare SSIDs live, beide APs, beide Bänder, je SSID→VLAN** (wifi datapath vlan-id): `dirtyvader-main`(10, WPA3-only, FT), `-iot`(30, **nur 2,4 GHz**, WPA2+3), `-media`(40, WPA2+3, **FT=no** wg. Sonos), `-untrusted`(50, WPA2+3), `-guest`(90, WPA2+3). Alt-SSIDs `install*`/`BF-Main`/`wv*` entfernt. Temp-PSK (User setzt echte). @@ -205,7 +215,11 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na → Map dokumentiert statt umbenannt. Backups `bf-ap{1,2}-pre-nomen-20260702.backup`/`.rsc` auf den Geräten. - ⏳ **Offene Coverage-Arbeit → ausgelagert nach TP3.3** (Fortsetzung in neuer Session). -### TP3.3 — WLAN Coverage-Kur ▸ 🔜 TODO (Fortsetzung, neue Session) — `docs/wifi-p750w-coverage-and-map.md` +### TP3.3 — WLAN Coverage-Kur ▸ 📜 **IN TP25 AUFGEGANGEN (2026-08-17)** — offene Arbeit steht dort, nicht hier +> ⚠️ Der Header sagte bis 2026-08-19 „🔜 TODO (Fortsetzung, neue Session)" — dieselbe Falle wie bei TP3: +> ein Status, der nicht mitgezogen wurde. Der Re-Walk und die Dead-Spot-Kartierung sind **Schritt 5 von +> TP25** und zwar bewusst **nach** den Funkparameter-Fixes; die 802.11k/v-Reparatur ist am 2026-08-13 +> erledigt worden. Was hier steht, ist Begruendung und Messhistorie. - ✅ **BEHOBEN 2026-08-13, noch am selben Abend (User: „aus Zeitgründen zuerst 11k/v, der nächste Call steht an").** `st-main` (`rrm=yes wnm=yes neighbor-group=bf-main`) auf beiden APs wiederhergestellt und an `cfg-main-5g`/`cfg-main-2g` gehängt — **via GC-ConfigPlan**, bewusst nicht per Direkt-Write: der Push läuft so NAS→Kabel→AP und nicht über die WLAN-Verbindung, die man gerade umkonfiguriert. `/system backup` je AP davor (`ap{1,2}-pre-steering-20260813.backup`). **Gegengeprüft am Gerät** (nicht am Plan-Status): `st-main rrm=true wnm=true ng=bf-main`, beide Main-Configs verweisen darauf. - ⚠️ **Erwartete Nebenwirkung: alle Clients haben kurz reassoziiert** (ap1 25→2, ap2 7→14 unmittelbar danach) — `steering=` auf einer `wifi configuration` zu setzen re-applied die VAPs, auch die nicht angefassten. Nach ~2 Min eingependelt (ap1 15 / ap2 13, VLAN30 = 28 Hosts auf der Core-Bridge). **Nicht während eines Calls machen.** - ✅ **In GC verankert:** Steering steht jetzt im AP-Zweig des Templates (`st-main`/`bf-main` als Konstante — es gibt genau eine Roaming-Domain pro Standort) + neues ComplianceFeature **`wifi-steering`**. Eine künftige Neuprovisionierung kann es damit nicht mehr stillschweigend verlieren — genau das war der Fehler vom 2026-08-08. @@ -640,7 +654,11 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2, s. TP2.1 — Solo/Interim bis CRS-Tausch) + Cudy ab. - ✅ **CRS = RouterOS-fähig → in-model:** MikroMCP-Write + Nautobot Golden Config (TP21) managen auch die **Switches**, nicht nur den Router → config-as-code deckt den **ganzen Kabel-Fabric**. (SwOS-Boot bliebe als Fallback möglich, aber nicht genutzt.) - ⚠️ **kein PoE** (Sonoff/PoE-Verbraucher via Injektor, falls nötig). -- **📶 WLAN bleibt hAP ax²** — kein Hardware-/Ecosystem-Wechsel. ⚠️ **Überholt am 2026-07-22/2026-08-08: ~~/CAPsMAN~~** — CAPsMAN ist abgeschafft, beide APs laufen seit dem Rebuild als **Standalone-APs aus der Golden Config** (s. TP3). Die Hardware-Aussage gilt unverändert. Coverage-Schwachstellen (P750W-Fall, Terrasse/Kanten) bleiben Platzierungs-/Roaming-Thema von **TP3.3**, nicht durch neue Hardware gelöst. +- **📶 WLAN bleibt hAP ax²** — kein Hardware-/Ecosystem-Wechsel; die Hardware-Aussage gilt unverändert. + ⚠️ **Die Betriebsart hat zweimal gewechselt, letzter Stand ist CAPsMAN:** CAPsMAN abgeschafft + (2026-07-22/08-08, TP3-Rebuild → Standalone-APs) → **wieder eingeführt am 2026-08-17 (TP28), Manager + ist `crs326-core`, ap1/ap2 sind reine CAPs.** Wer hier nur bis zum ersten Pfeil liest, baut auf einem + überholten Stand auf. Coverage-Schwachstellen (P750W-Fall, Terrasse/Kanten) bleiben Platzierungs-/Roaming-Thema von **TP3.3**, nicht durch neue Hardware gelöst. - **🧭 Router-HW final (User-Entscheid 2026-07-22): kein RB5009.** Kein Zukauf einer dedizierten Router-HW. - **🔄 KORREKTUR (User-Entscheid 2026-07-22, später am selben Tag): der CRS326-Core WIRD der neue L3-Router.** Die frühere Fassung dieser Zeile („Router bleibt dauerhaft ap1/ap2, L3/CAKE/Firewall bleiben auf ap1") ist damit **überholt**. **Routing, DNS und DHCP wandern vollständig von ap1 auf `crs326-core`**; ap1/ap2 werden zu **reinen Access Points**. Auch der CF-Mesh-Endpoint terminiert dort (s. TP16.1, war schon vorher auf CRS326 retargetet — passt jetzt konsistent zusammen). Damit entfallen die `device-mode=home`-Einschränkungen des hAP (kein scheduler/fetch) für die Router-Rolle. **Reihenfolge (User): erst Switches aufsetzen und in Betrieb nehmen, danach WLAN-Neuprovisionierung der APs.** Betroffen/nachzuziehen: TP4 (Router-Rolle), TP5/TP6 (Firewall + CAKE landen auf dem CRS326), TP21 (Scope-Grenze). - **📍 CRS326 Live-Stand (2026-07-22, via MNDP von ap1):** **beide Geräte sind bereits am Netz und laufen** — RouterOS **7.19.5**, Werkszustand. `crs326-core` = MAC `04:F4:1C:B4:17:76` (software-id `4W04-URHT`), `crs326-branch` = MAC `04:F4:1C:B4:15:58` (`RGZJ-UK0T`). ⚠️ **Beide auf Werks-IP `192.168.88.1` im selben L2-Segment = IP-Konflikt** → beim Bring-up nur eines nach dem anderen adressieren, Unterscheidung ausschließlich per MAC. Die frühere Notiz „Uplink-Port bislang ungenutzt/down" ist überholt. **Standorte: `crs326-core` = „Technik UG" (virtueller Technikbereich im UG/Diele, KEIN Keller), `crs326-branch` = „Technik OG".** @@ -1261,8 +1279,10 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - ⚠️ **Nebenbefund:** die TP3.2-Access-List, die den P750W an ap1 pinnte („überlebt ap2-Re-Provision"), ist **beim Rebuild 2026-08-08 verlorengegangen** — im Export beider APs steht keine einzige Access-List-Zeile. Laut CLAUDE.md ist der Pin nicht mehr nötig (L3-GW liegt auf dem Core), der **Verlust war aber unbemerkt.** -- `ft=yes ft-over-ds=no` ist dagegen **korrekt** für Standalone-APs (over-DS bräuchte ein Inter-AP-Protokoll) — - kein Fund, nur zur Abgrenzung festgehalten. +- `ft=yes ft-over-ds=no` war **korrekt für den damaligen Standalone-Betrieb** (over-DS braucht ein + Inter-AP-Protokoll) — kein Fund, nur zur Abgrenzung festgehalten. + 📌 **Seit TP28 gilt das nicht mehr:** unter CAPsMAN ist **`ft-over-ds=yes`** aktiv, weil der Manager + genau dieses Inter-AP-Protokoll mitbringt. #### 🟡 Fund F — IoT-Clients trennen exakt alle ~5:05 bei gutem Signal (offen, präzise vermessen) ``` @@ -1624,12 +1644,14 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". (`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. +- ✅ **~~OFFEN — das GC-Modell beschreibt weiter Standalone-APs~~ — ERLEDIGT am 2026-08-18.** Die + `wifi-*`-Features haengen jetzt am Core, das AP-Template ist auf die `cap`-Zeile eingedampft, und die + toten Standalone-Objekte sind von beiden APs abgeraeumt. Details im ersten Block dieses TPs. + Die hier genannte Zahl `76/76` ist damit doppelt ueberholt (aktuell 92/92 bei 23 Rules). + *(Der Absatz stand bis 2026-08-19 unveraendert als „OFFEN" hier, obwohl der Kopf des TPs schon + „KOMPLETT" sagte — ein Selbstwiderspruch im selben Abschnitt, ueber den prompt die naechste Session + gestolpert ist. Merkregel fuer kuenftige Statuswechsel: **nicht nur den Header umschreiben, sondern + die Punkte darunter mitziehen.**)* - 📌 **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`).