From c23628f62f79c24159ae2a81f4c58de4686f8b92 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Fri, 4 Sep 2026 19:39:13 +0200 Subject: [PATCH] TP25: ap3-FT-Drift behoben + Kanalplan committed (140/140) ap3 trug auf wifi1/wifi2 einen Werks-Inline security.ft=yes (Bring-up-Skript tp28-ap3-phase2-cap.rsc unset !ft-over-ds, aber nicht !ft; Abnahme zaehlt nur benannte security-Objekte -> Inline-Wert unsichtbar). Gemischtes FT-ESS = Strong-Signal-Abbrueche (-43/-45 dBm) NUR auf ap3 bei 3/3 Strichen. Live per !security.ft geradegezogen (uniform ft=no), Bring-up-Quelle korrigiert. Kanalplan committed: Template auf DFS-Frequenzlisten (ch-5g-ap1=5260,5280, ch-5g-ap2=5300,5320) + ap1-Provisioning-Zeilen (radio-mac ...E5/...E6) wieder aufgenommen. Push nach bf-golden-config + GitRepo-Sync + refresh-compliance -> 140/140, 0 Drifts; Transaktion TP25-kanalplan-ap1-live committed. Doku: Ist-Stand, Fund-E-Block, CLAUDE.md Punkt 5 (Merkregel: nach jeder sec-main-FT-Aenderung jeden CAP einzeln auf security.ft pruefen). Co-Authored-By: Claude Opus 4.8 --- CLAUDE.md | 7 +++++++ docs/teilprojekte.md | 20 +++++++++++++++----- nautobot/mikrotik_routeros.j2 | 21 +++++++++++---------- routeros/tp28-ap3-phase2-cap.rsc | 9 +++++++-- 4 files changed, 40 insertions(+), 17 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 700c9a3..ee8c699 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -20,6 +20,13 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der am 09-01 zurueckgebaut; Hebel 2–4 entfallen, **kein Geraete-Write** (Soll stand: `ft=yes ft-over-ds=yes`, **Compliance 140/140**). **Am 2026-09-04 hat Christoph `ft=no` auf `sec-main` als Dauerzustand entschieden** (Hebel 2 doch gezogen: Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen). + 🔴 **Nachtrag 09-04: `ft=no` war NICHT uniform.** ap3 trug einen Werks-Inline `security.ft=yes` auf + `wifi1/wifi2` (Bring-up unset `!ft-over-ds`, aber nicht `!ft`; Abnahme zählt nur benannte + security-Objekte → Inline-Wert unsichtbar). Gemischtes FT-ESS → Strong-Signal-Abbrüche (−43/−45 dBm) + **nur auf ap3** bei 3/3 Strichen. Fix: `!security.ft` auf ap3 (uniform `ft=no`), Quelle + `tp28-ap3-phase2-cap.rsc` korrigiert. **Merkregel: nach jeder `sec-main`-FT-Änderung jeden CAP einzeln + `get wifiN security.ft` prüfen — CAP-lokale Inline-Overrides sind compliance-unsichtbar.** + Der TP25-Kanalplan ist am 09-04 committed (DFS-Frequenzlisten + ap1-Provisioning, **140/140, 0 Drifts**). Offen in TP25 bleibt nur **ap2 unterperformt** (2 m/−80 dBm). Vorstufen: [Befund](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md) · [Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md) · diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index ef3f120..335150a 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -28,10 +28,13 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` · ## Ist-Stand (Kurz) **Stand 2026-09-04 — live gegen die Geräte geprüft (MikroMCP/REST/SSH), nicht aus der Doku abgeschrieben.** -**Compliance 138/140** — 2 Drifts, beide aus der Kanalplan-Arbeit: `wifi-channel` (offene Transaktion -`TP25-kanalplan-ap1-live`, im Scope) + `wifi-provisioning` (ap1-Provisioning-Regeln, **AUSSERHALB** des -Transaktions-Scopes — Side-Effect des ap1-Reaktivierens). `wifi-security` gruen seit 2026-09-04 (`ft=no` -auf `sec-main`, s. unten). +**Compliance 140/140, 0 Drifts** (2026-09-04 nachmittags). Der TP25-Kanalplan ist **committed**: +Template auf DFS-Frequenz-Listen umgestellt (`ch-5g-ap1=5260,5280`, `ch-5g-ap2=5300,5320`) + die +ap1-Provisioning-Zeilen wieder aufgenommen → Transaktion `TP25-kanalplan-ap1-live` geschlossen und der +`wifi-provisioning`-Drift weg. `wifi-security` gruen (`ft=no` auf `sec-main`). +🔴 **Zusätzlich live behoben (nicht compliance-sichtbar):** ap3 trug auf `wifi1/wifi2` einen Werks-Inline +`security.ft=yes` — gemischtes FT-ESS, das die 3/3-Strich-Abbrüche vom 09-04 erklärt. Unset → uniform +`ft=no` on-air; Bring-up-Quelle `tp28-ap3-phase2-cap.rsc` um `!security.ft` ergänzt (s. Fund-E-Block). *(Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt. Wer diesen Block liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)* - ✅ **TP25 Multi-Pin-Konsole (2026-09-04):** die Klick-Konsole (`docs/tp6-marker/server.py`) ist auf @@ -46,7 +49,14 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d 1d18h, `caps joined=0` → keine Reboot-Artefakte). ⇒ **7.24.1 (TP27) war die Ursache/der Fix, nicht `ft-over-ds`.** Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen, **kein Geräte-Write**. **Am 2026-09-04 hat Christoph `ft=no` auf `sec-main` als Dauerzustand entschieden** (Hebel 2 doch gezogen, - Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen). Offen in + Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen). 🔴 **Nachtrag 2026-09-04:** „ohne FT" + galt bis dahin **nur für Manager/ap1/ap2** — **ap3** trug einen Werks-Inline `security.ft=yes` auf + `wifi1/wifi2` (Bring-up-Skript unset `!ft-over-ds`, aber nicht `!ft`; die Abnahme zählt nur benannte + security-Objekte und sah den Inline-Wert nicht). Das ist ein **gemischtes FT-ESS** und erklärt den + Abbruch bei 3/3 Strichen: Log zeigte wiederkehrende Strong-Signal-Disconnects (−43/−45 dBm) **nur auf + ap3** (`cap-wifi2/4`, `dirtyvader-main`). Fix: `!security.ft` auf ap3 → uniform `ft=no`; Quelle + korrigiert. **Merkregel: nach jeder `sec-main`-FT-Änderung jeden CAP einzeln auf `security.ft` prüfen — + CAP-lokale Inline-Overrides sind compliance-unsichtbar.** Offen in TP25 bleibt nur der separate Punkt **ap2 unterperformt** (2 m/−80 dBm). Handoff: [`docs/handoff-20260902-tp25-fund-e-messung.md`](handoff-20260902-tp25-fund-e-messung.md). - ⏸️ **TP41 CF-Access-Reparatur — ZURÜCKGESTELLT 2026-09-01 (User-Entscheid; Rest wartet auf Info):** Session 720h, diff --git a/nautobot/mikrotik_routeros.j2 b/nautobot/mikrotik_routeros.j2 index d5fd25d..197929e 100644 --- a/nautobot/mikrotik_routeros.j2 +++ b/nautobot/mikrotik_routeros.j2 @@ -203,8 +203,11 @@ # Literal-Block wie die L2-Fabric: Radio-MACs und Kanalzuordnung sind # geraetegebunden und in Nautobot nicht modelliert. Aenderungen daran sind # bewusst sichtbare Template-Aenderungen. -/interface wifi channel add band=5ghz-ax frequency=5180 name=ch-5g-ap1 width=20/40mhz -/interface wifi channel add band=5ghz-ax frequency=5220 name=ch-5g-ap2 width=20/40mhz +# ap1/ap2 auf Band B (DFS) seit dem TP25-Kanalplan-Umzug (committed 2026-09-04). Frequenz-LISTE +# statt Einzelwert: bei einer Radar-Erkennung muss das Radio auf einen anderen Wert der Liste +# ausweichen koennen -- ein Einzelwert waere ein SPOF. ap1=52+56 (5260/Ce), ap2=60+64 (5300/Ce). +/interface wifi channel add band=5ghz-ax frequency=5260,5280 name=ch-5g-ap1 width=20/40mhz +/interface wifi channel add band=5ghz-ax frequency=5300,5320 name=ch-5g-ap2 width=20/40mhz /interface wifi channel add band=2ghz-ax frequency=2412 name=ch-2g-ap1 width=20mhz /interface wifi channel add band=2ghz-ax frequency=2462 name=ch-2g-ap2 width=20mhz # ap3 (cAP ax, Technik UG) seit 2026-08-30. Kanaele aus dem TP25-Plan vom 2026-08-24: @@ -244,18 +247,16 @@ /interface wifi configuration add channel=ch-2g-ap3 country=Austria datapath=dp-main mode=ap name=cfg-main-2g-ap3 security=sec-main ssid=dirtyvader-main steering=st-main /interface wifi configuration add country=Austria datapath=dp-guest mode=ap name=cfg-guest security=sec-guest ssid=dirtyvader-guest steering=st-guest /interface wifi capsman set ca-certificate=auto certificate=auto enabled=yes interfaces=vlan99 upgrade-policy=none -# 🔴 ap1 hat BEWUSST keine Provisioning-Zeile (2026-08-30). ap3 hat in Technik UG seinen -# Platz uebernommen und funkt dort auf 5180; ap1 steht bis zu seinem Umzug ans Sideboard -# direkt daneben und wuerde auf demselben Kanal kollidieren. Ohne passende Regel legt -# CAPsMAN fuer ein Radio gar nichts an -> es bleibt still, das Geraet aber erreichbar. -# Die Objekte `ch-5g-ap1`/`ch-2g-ap1` und `cfg-main-*-ap1` bleiben absichtlich stehen: -# beim Umzug bekommt ap1 laut TP25 `5260/Ce` (Band B, DFS) -- dann werden nur diese -# zwei Zeilen wieder eingesetzt und das Channel-Objekt auf eine Frequenz-LISTE gestellt -# (mit nur einem Wert waere eine Radar-Erkennung ein SPOF). +# ap1 ist ans Sideboard umgezogen (TP25-Kanalplan committed 2026-09-04) und hat wieder eine +# Provisioning-Zeile: Band B `5260/Ce` (5G) + ch1 (2,4G). Die frueher bewusst weggelassenen +# Zeilen (2026-08-30, ap1 stand neben ap3 auf 5180 und haette kollidiert) sind damit +# gegenstandslos. Reihenfolge wie am Geraet: ap2, ap3, ap1. /interface wifi provisioning add action=create-dynamic-enabled comment="ap2 5GHz" master-configuration=cfg-main-5g-ap2 radio-mac=D0:EA:11:4D:40:3E slave-configurations=cfg-media,cfg-untrusted,cfg-guest /interface wifi provisioning add action=create-dynamic-enabled comment="ap2 2.4GHz" master-configuration=cfg-main-2g-ap2 radio-mac=D0:EA:11:4D:40:3F slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest /interface wifi provisioning add action=create-dynamic-enabled comment="ap3 5GHz" master-configuration=cfg-main-5g-ap3 radio-mac=D0:EA:11:FF:16:9F slave-configurations=cfg-media,cfg-untrusted,cfg-guest /interface wifi provisioning add action=create-dynamic-enabled comment="ap3 2.4GHz" master-configuration=cfg-main-2g-ap3 radio-mac=D0:EA:11:FF:16:A0 slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest +/interface wifi provisioning add action=create-dynamic-enabled comment="ap1 5GHz" master-configuration=cfg-main-5g-ap1 radio-mac=D0:EA:11:4D:40:E5 slave-configurations=cfg-media,cfg-untrusted,cfg-guest +/interface wifi provisioning add action=create-dynamic-enabled comment="ap1 2.4GHz" master-configuration=cfg-main-2g-ap1 radio-mac=D0:EA:11:4D:40:E6 slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest # [6c] WLAN ACCESS-LIST — der Soll-Zustand ist LEER, und das ist eine Aussage. # diff --git a/routeros/tp28-ap3-phase2-cap.rsc b/routeros/tp28-ap3-phase2-cap.rsc index 942713e..dd211e3 100644 --- a/routeros/tp28-ap3-phase2-cap.rsc +++ b/routeros/tp28-ap3-phase2-cap.rsc @@ -22,8 +22,13 @@ /interface wifi datapath remove [find] /interface wifi channel remove [find] # Werks-Inline-Overrides auf den Master-Radios loeschen, sonst gewinnen sie gegen den Manager. -/interface wifi set [find name=wifi1] !configuration.ssid !security.authentication-types !security.passphrase !security.ft-over-ds -/interface wifi set [find name=wifi2] !configuration.ssid !security.authentication-types !security.passphrase !security.ft-over-ds +# 🔴 `!security.ft` MUSS mit dabei sein: die Werks-cAP-Radios kommen mit ft=yes; ohne diesen +# unset bleibt er stehen und sendet dirtyvader-main mit FT, waehrend ap1/ap2 (ft geerbt=no) +# es nicht tun -> gemischtes FT-ESS, Strong-Signal-Abbrueche NUR auf ap3. Genau das war der +# Fall am 2026-09-04: die Abnahme unten zaehlt nur BENANNTE security-Objekte (=0) und sieht +# den Inline-Wert auf wifi1/wifi2 nicht. Nachtraeglich behoben 2026-09-04. +/interface wifi set [find name=wifi1] !configuration.ssid !security.authentication-types !security.passphrase !security.ft !security.ft-over-ds +/interface wifi set [find name=wifi2] !configuration.ssid !security.authentication-types !security.passphrase !security.ft !security.ft-over-ds # --- (2) L3-Reste des Werks-Routers weg (jetzt gefahrlos: die WLAN-Sitzung ist ohnehin tot) --- /ip dhcp-server remove [find]