From 77553c94af686b8e8b7cffa7b591fcda4a0f089b Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 17 Aug 2026 15:01:00 +0200 Subject: [PATCH] =?UTF-8?q?TP25:=20Drift-Luecke=20geschlossen=20(72/72)=20?= =?UTF-8?q?=E2=80=94=20und=20zwei=20fehlende=20Compliance-Sektionen=20aufg?= =?UTF-8?q?edeckt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Die neuen Funkparameter stehen jetzt in der SoT, nicht nur auf dem Geraet: radios[5g].width 20/40/80mhz -> 20/40mhz, DEVICE_CHANNELS[ap2][5g] 149 -> 44. Config-Context gepatcht, dann Backup -> Intended -> Compliance: 72/72, keine Drifts. Ein kuenftiger Deploy kann die Fixes damit nicht zurueckdrehen. Bemerkenswert: width fuer 2,4 GHz stand im Config-Context die ganze Zeit korrekt auf 20mhz. Die SoT war richtig, das Geraet hat sie nicht befolgt — der Beweis, dass das Problem der Inline-Override war und nicht die Datenlage. Beim Nachpruefen, ob "72/72" die Funkparameter ueberhaupt abdeckt, sind zwei Luecken aufgefallen (18 Compliance-Rules abgefragt): - /interface wifi (Interface-Sektion) hat KEINE Rule. Die fuenf wifi-*-Features decken nur die Profilobjekte ab. Die Inline-Overrides leben in der Interface-Sektion — deshalb blieben Fund A und D seit 2026-08-08 unentdeckt, waehrend die Flotte durchgehend "compliant" meldete. - /ip firewall filter hat KEINE Rule, es gibt nur ip-firewall-nat. Die TP5-Zeile "laeuft ueber ip-firewall-*-Features aus TP22" war damit irreführend. Die 11 Etappe-2-Regeln und der kommende Deny-by-default sind nicht drift-ueberwacht; "72/72" sagt ueber die Firewall nichts aus. -> als Vorbedingung fuer TP5 Etappe 3 eingetragen. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 34 ++++++++++++++++++++++++----- nautobot/ingest-ap-configcontext.py | 12 ++++++++-- 2 files changed, 39 insertions(+), 7 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 06bc001..e18e937 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -1098,8 +1098,29 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". einzige verbleibende Griff gegen klebende Clients.)* 5. **Re-Walk + Dead-Spot-Kartierung** (der übernommene TP3.3-Rest) — **erst jetzt**, gegen die korrigierte Basis. Vorher gemessene Werte sind wertlos. -6. **Compliance-Feature** auf `/interface/wifi channel` + `/interface/wifi` erweitern, damit A und D nicht - wiederkommen. +6. ⏳ **Drift-Lücke — Teil 1 GESCHLOSSEN, Teil 2 offen und jetzt exakt vermessen (2026-08-17).** + - ✅ **Der akute Teil ist zu:** die neuen Werte stehen in der SoT (`nautobot/ingest-ap-configcontext.py`: + `radios[5g].width` `20/40/80mhz`→`20/40mhz`, `DEVICE_CHANNELS[ap2][5g]` `149`→`44`), Config-Context + gepatcht, dann **Backup → Intended → Compliance** → **72/72, keine Drifts.** Damit kann ein künftiger + Deploy die Fixes **nicht** mehr zurückdrehen. *(Bemerkenswert: `width` für 2,4 GHz stand dort die ganze + Zeit korrekt auf `20mhz` — die SoT war richtig, nur das Gerät hat sie nicht befolgt. Der Beweis, dass + das Problem der Inline-Override war und nicht die Datenlage.)* + - 🔴 **Der Erkennungsteil bleibt offen. Die 18 Compliance-Rules abgefragt — es fehlen genau zwei Sektionen:** + | vorhanden | fehlt | + |---|---| + | `/interface wifi channel` · `… configuration` · `… datapath` · `… security` · `… steering` | **`/interface wifi`** (die Interface-Sektion) | + | `/ip firewall nat` | **`/ip firewall filter`** | + - **Folge 1 (WLAN):** die fünf `wifi-*`-Features decken nur die **Profil**objekte ab. Die Inline-Overrides + leben in `/interface wifi` — **deshalb sind Fund A und D seit dem 2026-08-08 unentdeckt geblieben, obwohl + die Flotte durchgehend „compliant" meldete.** Genau die Lücke, die ich unter Beobachtung 5 vermutet hatte; + sie ist jetzt belegt, nicht vermutet. Erschwerend: die VAP-MAC-Adressen sind gerätespezifisch (Template + Zeile ~220 nimmt sie bewusst raus), eine Rule auf diese Sektion braucht also erst + `local_config_context_data` je AP. + - 🔴 **Folge 2 (und die ist gewichtiger): `/ip firewall filter` ist NICHT abgedeckt.** Die TP5-Zeile + „läuft über Nautobot GC (`ip-firewall-*`-Features aus TP22)" ist damit **irreführend — es existiert nur + NAT.** Die 11 Etappe-2-Regeln und der kommende Deny-by-default sind **nicht drift-überwacht**: + „72/72 compliant" sagt über die Firewall **gar nichts**. ➡️ **Das gehört VOR TP5 Etappe 3**, denn eine + Drop-Regel, die niemand überwacht, ist genau die, die still verschwindet. - ⚠️ **`steering=`/Channel-Änderungen re-applien alle VAPs und werfen jeden Client kurz raus** (TP3.3 am 2026-08-13 gemessen: ap1 25→2, ap2 7→14). **Nicht während eines Calls deployen.** `/system backup` je AP vorher. - **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Übernimmt den offenen Rest von **TP3.3**, verwandt **TP3.2** (Coverage-Doku @@ -1179,9 +1200,12 @@ TP5 E1 ✅ ──► TP5 E2 ✅ ──► [mehrtägiges stilles Fenster] ── 2. ✅ **TP5 Etappe 2 — 11 Whitelist-Regeln** (2026-08-17, ConfigPlan `86fbd528`). Log-Regel verstummt. 3. ⏳ **Wartezeit, kein Arbeitsschritt:** das Log muss **mehrere Tage** still bleiben. 70 Sekunden Stille sind keine Aussage — es gibt Geräte, die einmal pro Woche funken. **Das ist das Gate, nicht eine Meinung.** -4. 🔜 **TP5 Etappe 3 — Drop scharf schalten.** Vorbedingungen: das stille Fenster **und** D2 (iPhone `.30.201` - ins MAIN-SSID, Hands-on Christoph). 🛟 Auto-Revert-Scheduler davor (auf dem Core möglich, `device-mode` - erlaubt scheduler — auf den hAPs nicht). +4. 🔜 **TP5 Etappe 3 — Drop scharf schalten.** Vorbedingungen: das stille Fenster · D2 (iPhone `.30.201` + ins MAIN-SSID, Hands-on Christoph) · **und neu: eine Compliance-Rule auf `/ip firewall filter`.** + 🔴 **Am 2026-08-17 festgestellt: die Filter-Kette ist NICHT drift-überwacht** — es gibt nur + `ip-firewall-nat`. Eine Deny-by-default-Regel ohne Drift-Erkennung ist genau die, die still verschwindet + und niemandem auffällt, bis etwas nicht mehr geht. **Siehe TP25 Schritt 6.** + 🛟 Auto-Revert-Scheduler davor (auf dem Core möglich, `device-mode` erlaubt scheduler — auf den hAPs nicht). 5. 🔜 **TP5 Etappe 4 — UNTRUSTED/GUEST Internet-only + MGMT isolieren** (`seal-lan` verengen → schaltet zugleich die 5 toten mDNS-`input`-Regeln scharf). **Mit im Paket:** TP7.1 (SSDP-Reflector für die macOS-Sonos-App) — gemeinsam testen, sonst prüft man zweimal dieselbe Strecke. diff --git a/nautobot/ingest-ap-configcontext.py b/nautobot/ingest-ap-configcontext.py index a83d153..9c9732d 100644 --- a/nautobot/ingest-ap-configcontext.py +++ b/nautobot/ingest-ap-configcontext.py @@ -55,7 +55,11 @@ AP_COMMON = { "native_vlan": 1, # Liste (nicht Dict): Reihenfolge ist garantiert und diffbar. "radios": [ - {"key": "5g", "iface": "wifi1", "band": "5ghz-ax", "width": "20/40/80mhz", "prefix": "w5"}, + # TP25 (2026-08-17): 80 -> 40 MHz. Im ETSI-Indoor-Band (5180-5240) gibt es nur + # EINEN 80-MHz-Block (ch36-48) - zwei APs koennen dort nicht beide 80 MHz fahren, + # ohne sich zu ueberlappen. Genau daran war ap2 auf ch149 (Band C) gelandet und + # sendete dort mit 9 statt 18 dBm. Mit 40 MHz passen beide ins Indoor-Band. + {"key": "5g", "iface": "wifi1", "band": "5ghz-ax", "width": "20/40mhz", "prefix": "w5"}, {"key": "2g", "iface": "wifi2", "band": "2ghz-ax", "width": "20mhz", "prefix": "w2"}, ], # main laeuft auf den MASTER-Radios (2 configurations mit channel=), @@ -83,8 +87,12 @@ AP_COMMON = { # ap1 ch36 -> 5180, ch1 -> 2412 # ap2 ch149-> 5745, ch11 -> 2462 DEVICE_CHANNELS = { + # 5 GHz mit 40 MHz: ap1 ch36 belegt 5170-5210 (36+40), ap2 ch44 belegt 5210-5250 + # (44+48) -> benachbart, ueberlappungsfrei, beide mit /I-Indoor-Freigabe und 18 dBm. + # ap2 war bis 2026-08-17 auf ch149 (5745, ETSI-Band C) und dort auf 9 dBm gedrosselt. + # 2,4 GHz: ch1/ch11 mit 20 MHz -> ueberlappungsfrei, ch6 bleibt fuer die Nachbarschaft frei. "ap1": {"5g": 36, "2g": 1}, - "ap2": {"5g": 149, "2g": 11}, + "ap2": {"5g": 44, "2g": 11}, } CTX_NAME = "ap-common"