From 14aa4f314272b15852d83f36ff30d008fc60cd59 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 17 Aug 2026 14:44:40 +0200 Subject: [PATCH] TP5 Etappe 2 ausgerollt + TP25/TP16.3 angelegt, TP25 Schritte 1-3 durch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit TP5 Etappe 2: 11 Whitelist-Regeln auf crs326-core, abgeleitet aus 43.027 Logzeilen (21 h) statt geraten. D1 = MAIN->INFRA pauschal, D4 = MGMT named sources (HA:8728, Nautobot:22, MAIN, cf-mesh), D5 = 8123 + MQTT. Log-Regel ist im Moment des Deploys verstummt; Zaehler steht. Etappe 3 bleibt gated auf ein mehrtaegiges stilles Fenster + D2 (iPhone aus dem IOT-SSID). TP25 neu — WLAN-Stabilisierung, Sammel-TP fuer Christophs Beobachtungen 1-6. Schritte 1-3 durch, alles am Geraet gegengeprueft: - w2-iot trug einen channel.*-Override auf einem Slave-VAP (auf ap1 sogar 2ghz-n gegen einen 2ghz-ax-Master) -> Mechanismus hinter "-iot mal da, mal nicht". Danach auf beiden APs BR/running. - 2,4 GHz lief auf 40 MHz, obwohl ch-2g width=20mhz sagt: ein Inline-Override auf wifi2 gewinnt gegen das Profil. Jetzt 20 MHz, ap1 ch1 / ap2 ch11. - ap2s 5-GHz-Radio sendete mit 9 dBm, jetzt 18. Beide APs 40 MHz, ueberlappungsfrei (5170-5210 / 5210-5250). Drei Korrekturen an eigenen Annahmen: - Die 9 dBm sind NICHT das ETSI-Band C. Der Wechsel ins Indoor-Band liess sie bei 9; erst die Breite brachte 18. "80 MHz generell" traegt auch nicht, ap1 fuhr 80 MHz mit 18. Mechanismus offen, Hypothese + Test in TP25. - `!channel` loescht Inline-Overrides nicht, nur !channel.width einzeln. - Frequenz vor Breite zu aendern hat ap2 kurzzeitig in denselben 80-MHz-Block wie ap1 geschoben. Breite VOR Frequenz. Die ch149-Notiz ist bis 03f328f (2026-06-18) zurueckverfolgt: geloest wurde Co-Channel, nicht DFS. "non-DFS" war nachtraeglich mitgeschriebene Begruendung fuer das FCC-Standardpaar 36/149, keine geprueft Anforderung. Und skip-dfs-channels=10min-cac schliesst DFS gar nicht aus, nur das Wetterradar-Band -> 5500-5700 liegt als Reservekanalraum brach. TP16.3 neu — cloudflared-Reduktion: der Mesh IST schon der private Datenpfad (137 Zeilen im TP5-Log belegen es), Container braucht nur der oeffentliche Ingress. Mesh-Hostname-Routes fuer public hostnames sind Egress, nicht Publishing — Verwechslungsfalle. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 111 ++++++++++++++++--- routeros/tp25-schritt1-3-ap1.rsc | 35 ++++++ routeros/tp25-schritt1-3-ap2.rsc | 43 +++++++ routeros/tp25-schritt2-fix-overrides-ap2.rsc | 42 +++++++ 4 files changed, 218 insertions(+), 13 deletions(-) create mode 100644 routeros/tp25-schritt1-3-ap1.rsc create mode 100644 routeros/tp25-schritt1-3-ap2.rsc create mode 100644 routeros/tp25-schritt2-fix-overrides-ap2.rsc diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 4b6a555..06bc001 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -880,7 +880,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.** - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen). -### TP25 — WLAN-Stabilisierung: Best-Practice-Audit statt Bauchgefühl ▸ ⏳ **AUDIT DURCH (2026-08-17), Umsetzung offen** — Sammel-TP für Christophs Beobachtungen 1–6 +### TP25 — WLAN-Stabilisierung: Best-Practice-Audit statt Bauchgefühl ▸ ⏳ **SCHRITTE 1–3 DURCH (2026-08-17): beide APs 18 dBm, 20 MHz auf 2,4, überlappungsfrei** — offen: Signal-Boden + Re-Walk — Sammel-TP für Christophs Beobachtungen 1–6 > **Warum eigener TP:** Christoph hat am 2026-08-16/17 sechs konkrete Beobachtungen gemeldet und ausdrücklich > **einen** TP dafür verlangt. Sie hängen alle an derselben Ursache-Klasse (Funkparameter, die nicht nach Manual > gesetzt sind), gehören also zusammen. **TP25 übernimmt den offenen Rest von TP3.3** (Re-Walk, Dead-Spot-Kartierung) @@ -915,12 +915,26 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **Gemessen:** ap1 `wifi1` `tx-power: 18`, ap2 `wifi1` **`tx-power: 9`** — bei identischer Hardware und identischem Profil. **9 dB Unterschied = Faktor ~8 in der Leistung**, ap2s 5-GHz-Zelle hat grob ein Drittel des Radius von ap1. -- **Ursache ist regulatorisch, nicht defekt:** ap2 ist auf **5745 MHz (ch149)** gepinnt. Die Regulatory-Tabelle - des Radios für `country=Austria` listet `5745/ax/Ceee` **ohne** `/I`-Flag (indoor) und **ohne** `/D` (DFS) — - ETSI-Band C, erlaubt, aber **hart leistungsbegrenzt**. ap1 auf **5180 MHz** bekommt `5180/ax/Ceee/I`, also die - Indoor-Freigabe mit voller Leistung. ⚠️ **Die TP3-Notiz „Kanäle non-DFS ap1 ch36/ch1, ap2 ch149/ch11" ist eine - FCC-Denkweise.** Non-DFS ist ch149 unter ETSI tatsächlich — aber eben zum Preis der Sendeleistung. Das war der - unbemerkte Tauschhandel. +- ✅ **BEHOBEN 2026-08-17: ap2s 5-GHz-Radio läuft jetzt mit 18 dBm** (`5220/ax/Ce/I`). Messreihe am Gerät: + | Zustand | Kanal | tx-power | + |---|---|---| + | ap2 vorher | `5745/ax/Ceee` (80 MHz, ohne `/I`) | **9** | + | ap2 nach Frequenzwechsel | `5220/ax/eeCe/I` (80 MHz, mit `/I`) | **9** ⬅️ unverändert! | + | ap2 nach Breitenkorrektur | `5220/ax/Ce/I` (40 MHz) | **18** ✅ | + | ap1 durchgehend | `5180/ax/Ceee/I` → `5180/ax/Ce/I` | 18 → 18 | +- 🔴 **Ehrliche Korrektur: meine erste Begründung war falsch, und die zweite auch nicht vollständig.** + Ich hatte die 9 dBm auf **ETSI-Band C** (ch149 ohne `/I`-Flag) zurückgeführt. **Widerlegt:** der Wechsel ins + Indoor-Band bei gleicher Breite ließ die Leistung auf 9 dBm. „80 MHz kostet generell Leistung" trägt auch + nicht — **ap1 fuhr 80 MHz im selben Band mit 18 dBm.** Der Fix ist gemessen, der Mechanismus ist es nicht. +- 🔬 **Kohärente Resthypothese (nicht bewiesen, aber testbar):** es sind **zwei** Effekte, je einer pro Kanal — + (a) `5745/Ceee` = ETSI-Band-C-Limit (die erste Theorie gilt für *diesen* Kanal weiter), und + (b) `5220/eeCe` = das Kontrollkanal liegt **nicht** am Blockanfang (`eeCe` statt `Ceee`), was das Radio + derated. Das würde ap1s `5180/Ceee`=18 und ap2s `5220/eeCe`=9 gleichzeitig erklären. + **Diskriminierender Test:** ap2 testweise auf `5180/Ceee` — 18 dBm ⇒ Hypothese (b) trägt; 9 dBm ⇒ es ist + gerätespezifisch (dann ist ap2s Radio der Verdächtige, relevant für die Hardware-Frage!). **Nicht nötig für + den Betrieb, aber vor einem Hardwarekauf wissenswert.** +- ⚠️ **Die TP3-Notiz „Kanäle non-DFS ap1 ch36/ch1, ap2 ch149/ch11" hatte trotzdem keinen tragenden Grund** — + s. eigener Absatz „Herkunft der ch149-Notiz" unten. - 🎯 **Der Fix löst Fund B und C in einem Zug — und er ist nicht offensichtlich:** unter ETSI Austria existiert im Indoor-Band (5180–5240) **nur ein einziger 80-MHz-Block** (`5180/Ceee` = ch36–48). Zwei APs können dort also nicht beide 80 MHz fahren, ohne sich zu überlappen — **genau deshalb ist ap2 überhaupt auf 5745 gelandet.** @@ -1004,13 +1018,84 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". Einmalentscheidung, kein Laufzeitproblem — der Hauptvorteil von CAPsMAN greift hier also kaum. *(Wenn ein dritter AP dazukäme, wäre die Abwägung neu zu führen.)* +#### 🔎 Herkunft der ch149-Notiz (Christophs Frage 2026-08-17: „wie kam es zu dieser Notiz?") +- **Nachverfolgt bis Commit `03f328f`, 2026-06-18, CAPsMAN-Ära.** Wortlaut der Commit-Message: + *„Kanal-Plan non-DFS/überlappungsfrei: ap1 ch36+ch1, ap2 ch149+ch11 (Auto-Channel hatte beide APs auf + 5500-DFS/2437 gelegt = Co-Channel)"*. +- 🎯 **Das gelöste Problem war Co-Channel, nicht DFS.** Auto-Channel hatte beide APs auf **denselben** Kanal + gelegt; der Fix war, überhaupt zu pinnen. Dass die Wahl auf 36/149 fiel, ist das **FCC-Standardpaar** aus + jedem Tutorial — „non-DFS" wurde als Begründung *nachträglich* mitgeschrieben, war aber nie eine geprüfte + Anforderung. **Christophs Einschätzung ist damit belegt: es gibt keinen Grund, Frequenzbänder auszunehmen.** +- 📌 **Und ein Detail, das die Sache entschärft: `skip-dfs-channels=10min-cac` schließt DFS gar nicht aus.** + Es überspringt nur Kanäle, die die **10-Minuten**-CAC brauchen (Wetterradar-Band 5600–5650). Der Rest des + DFS-Bands bliebe nutzbar. Ausgeschlossen wurde DFS in Wahrheit durch das **harte `frequency=`-Pinning** — + wo nichts ausgewählt wird, wirkt kein Skip. (Die Overrides sind mit Schritt 2 ohnehin weg.) +- **Konsequenz für den Kanalplan:** das DFS-Band **5500–5700** ist eine echte Option und liegt bisher brach — + **11 zusätzliche Kanäle**, in ETSI ohne `/I`-Beschränkung. Preis: CAC-Wartezeit beim Start und im + Radar-Fall ein erzwungener Kanalwechsel (30 min Sperre). Bei Christophs aktuellem Symptombild + (Abbrüche) wäre ein radar-getriggerter Wechsel unangenehm — **deshalb jetzt nicht**, aber es ist der + Reservekanalraum, falls ein dritter AP dazukommt und 40 MHz nicht mehr reicht. + +#### 📡 Beobachtung 4b — „könnte `2ghz-g` nicht besser zu IoT passen?" +- **Verfügbar auf diesem Radio** (`/interface/wifi/radio`): `2ghz-g:20mhz` · `2ghz-n:20mhz,20/40mhz` · + `2ghz-ax:20mhz,20/40mhz`. +- ❌ **Für Reichweite bringt es nichts.** `band=` setzt die **höchste** angebotene Generation, nicht die + einzige — ein `2ghz-ax`-AP ist rückwärtskompatibel, g/n-Clients assoziieren normal. Und ein schwacher + Client fällt über die Ratenadaption von selbst auf die robusten niedrigen Raten. `band` ändert weder + Sendeleistung noch Empfängerempfindlichkeit. +- ✅ **Für Interoperabilität ist der Gedanke aber richtig.** Billige ESP-/Realtek-IoT-Stacks haben + dokumentierte Probleme mit 802.11ax-Beacons (HE-Capabilities, PMF). `2ghz-n` nimmt die HE-Elemente aus + dem Beacon und kann Assoziationswackler beheben — ein **Kompatibilitäts-**, kein Abdeckungsargument. +- 🎯 **Pointe: genau dieser Instinkt steckte schon im Fehler.** `channel.band=2ghz-n` auf `w2-iot` (Fund D) + war exakt der Versuch, IoT ein legacy-freundlicheres Band zu geben. **Die Absicht war richtig, der + Mechanismus falsch** — `band` ist eine Eigenschaft des **Radios**, nicht eines Slave-VAPs. Alle + 2,4-GHz-SSIDs teilen `wifi2`. +- **Empfehlung, falls Fund F (5-Minuten-Takt) nach dem Override-Fix bleibt:** `wifi2` global auf **`2ghz-n`** + — die saubere Version dessen, was der Override wollte. Kostet real nichts (kein 2,4-GHz-Client hier braucht + ax-Raten, `dirtyvader-main` auf 2,4 GHz ist ohnehin Fallback). **`2ghz-g` NICHT als ersten Schritt:** die + 20-MHz-Bindung ist richtig, aber 54 Mbit/s-Deckel und kein HT für *alle* 2,4-GHz-Clients ist ein echter + Verlust ohne Zusatznutzen gegenüber `n`. `g` ist die Eskalationsstufe, nicht der Einstieg. + +#### 🏠 Deckenmontage-APs — bringen sie einen echten Vorteil? (Christophs Überlegung 2026-08-17) +- **Der Gewinn liegt in Platzierung und Antennendiagramm, nicht im Silizium.** Ein cAP ax ist dieselbe + Chip-Generation und ebenfalls 2×2 wie der hAP ax² — **mehr Rohleistung gibt es nicht.** Was er gibt: + ein nach unten optimiertes Diagramm, freie Sichtlinien von der Decke, PoE-Montage ohne Möbel davor. +- 🔴 **Aber die Entscheidung wäre heute blind gewesen.** Vor dieser Session lagen ~9 dB auf ap2 brach + (Fund B), 2,4 GHz verschenkte ~3 dB an 40 MHz (Fund A) und der 5-GHz-Zellenrand ~3 dB an 80 MHz (Fund C). + **Hardware zu kaufen, um Fehlkonfiguration zu kompensieren, ist der teuerste Weg.** Genau das deckt sich + mit Christophs eigener Randbedingung („nicht kaufen, bevor alles aus dem AP raus ist"). +- ✅ **Jetzt ist der Boden gelegt** (beide APs 18 dBm, überlappungsfrei, 20 MHz auf 2,4). **Die Entscheidung + gehört an den Re-Walk (Schritt 5).** Bleiben danach Dead Spots — Terrasse, Kanten —, dann *ist* es ein + Platzierungsproblem, und Deckenmontage ist die richtige Antwort. Dann stellt sich aber zuerst die + billigere Frage: **reicht Umhängen der vorhandenen APs?** „Drehen hat nicht geholfen" passt zu einer + Abschattung, die Drehen nicht behebt — Versetzen schon. +- 📌 **Falls es auf drei APs hinausläuft, wird die CAPsMAN-Abwägung neu geführt** (s. Beobachtung 5): bei + 3 APs ist koordinierte Kanal-/Leistungsverwaltung erstmals ein Laufzeit- und nicht mehr ein + Einmalproblem. Und der diskriminierende Test aus Fund B (ist ap2s Radio gerätespezifisch schwach?) + gehört **vor** einen Kauf. + #### 📋 Umsetzungsreihenfolge (alles via GC, gestaffelt, ap2 zuerst) -1. **Fund D** — `channel.*`-Overrides von `w2-iot` entfernen (beide APs identisch). Kleinster Eingriff, klärt - Beobachtung 3 und ist Vorbedingung für die Fund-F-Messung. -2. **Fund A** — Inline-`channel.*` auf `wifi1`/`wifi2` leeren → 2,4 GHz fällt auf die profilkonformen 20 MHz. -3. **Fund B+C** — `ch-5g` auf `width=20/40mhz`, ap1 `frequency=5180`, **ap2 `frequency=5220`** → ap2 bekommt - +9 dBm, beide non-DFS Indoor, überlappungsfrei. -4. **Fund E** — `access-list` mit `signal-range`-Boden je AP; Schwellen erst nach dem Re-Walk festlegen. +1. ✅ **Fund D DURCH (2026-08-17)** — `channel.*`-Overrides von `w2-iot` auf **beiden** APs entfernt. + `w2-iot` ist danach auf ap1 **und** ap2 `BR` (bound + running) → Beobachtung 3 strukturell erledigt. + Dateien: `routeros/tp25-schritt2-fix-overrides-ap2.rsc`, `routeros/tp25-schritt1-3-ap1.rsc`. +2. ✅ **Fund A DURCH (2026-08-17)** — Inline-`channel.*` auf `wifi1`/`wifi2` geleert. **2,4 GHz läuft jetzt + auf 20 MHz** (`2412/ax` bzw. `2462/ax`, kein `Ce`/`eC` mehr), tx-power 15 dBm. ap1 ch1 / ap2 ch11 = + überlappungsfrei mit Platz für ch6 in der Nachbarschaft. +3. ✅ **Fund B+C DURCH (2026-08-17)** — `ch-5g` auf `width=20/40mhz`; ap1 `5180/ax/Ce/I`, ap2 `5220/ax/Ce/I`, + **beide 18 dBm** (ap2 vorher 9). Zellen benachbart, überlappungsfrei (5170–5210 / 5210–5250). + - 🔴 **GOTCHA, der zwei Deploys gekostet hat: `/interface/wifi/set !channel` löscht die + Inline-Sub-Property-Overrides NICHT** — es wirft nicht, es tut nichts. Danach stand `channel.width` + unverändert da, obwohl Profil *und* `configuration` korrekt auflösten. **Richtig ist einzeln: + `!channel.width !channel.band !channel.skip-dfs-channels`.** Dasselbe Muster wie der bekannte + `!configuration.ssid !security.*`-Griff aus dem TP3-Bring-up — nur nie auf `channel.*` angewandt. + - ⚠️ **Zwischenzustand war schlechter als der Ausgangszustand:** weil die Breite noch auf 80 MHz stand, + rutschte ap2 mit der neuen Frequenz in **denselben** 80-MHz-Block wie ap1 (beide ch36–48) = genau die + Co-Channel-Lage, die 2026-06-18 wegkonfiguriert werden sollte. **Merke: bei Kanalarbeit Breite VOR + Frequenz ändern**, sonst erzeugt man auf dem Weg eine Kollision. +4. 🔜 **Fund E** — `access-list` mit `signal-range`-Boden je AP; Schwellen erst nach dem Re-Walk festlegen. + *(Hinweis aus der P750W-Historie: `/interface/wifi` hat **kein** `disconnect-timeout`/`keepalive` mehr — + das gab es nur im alten `wireless`-Paket, AX-Radios können nicht zurück. Der Signal-Boden ist damit der + 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 diff --git a/routeros/tp25-schritt1-3-ap1.rsc b/routeros/tp25-schritt1-3-ap1.rsc new file mode 100644 index 0000000..4022a9f --- /dev/null +++ b/routeros/tp25-schritt1-3-ap1.rsc @@ -0,0 +1,35 @@ +# TP25 Schritt 1-3 auf ap1 — identisch zu ap2, mit der auf ap2 verifizierten Syntax. +# +# Reihenfolge bewusst: ap2 war zuerst (weniger kritisch), dort ist die Syntax +# am Geraet belegt. ap1 folgt erst jetzt. +# +# ⚠️ ap1 MUSS mit, sonst bleibt die Ueberlappung: ap1 auf 5180 mit 80 MHz +# belegt 5170-5250 und damit auch ap2s neue 40-MHz-Zelle bei 5220. +# Ziel: ap1 = 5180/Ce (ch36+40, 5170-5210), ap2 = 5220/Ce (ch44+48, +# 5210-5250). Benachbart, ueberlappungsfrei, beide 18 dBm. +# +# ap1-Besonderheit: w2-iot traegt hier ZUSAETZLICH channel.band=2ghz-n gegen +# einen 2ghz-ax-Master — der eigentliche Fund D. Deshalb !channel.band mit dabei. +# +# Push: python3 nautobot/gc-manual-plan.py --device ap1 \ +# --commands-file routeros/tp25-schritt1-3-ap1.rsc \ +# --change-id TP25-Funkparameter-ap1 --deploy +# Backup davor: ap1-pre-tp25-20260817.backup + +# --- Schritt 3 zuerst: Profil auf Sollwert, damit das Leeren unten direkt greift +:do { /interface/wifi/channel/set [find name=ch-5g] frequency=5180 width=20/40mhz } on-error={ :log info "tp25a1: 01 ch-5g warf" } +:do { /interface/wifi/channel/set [find name=ch-2g] frequency=2412 width=20mhz } on-error={ :log info "tp25a1: 02 ch-2g warf" } + +# --- Schritt 2: Inline-Overrides einzeln leeren (!channel allein tut NICHTS) - +:do { /interface/wifi/set [find default-name=wifi1] !channel.width } on-error={ :log info "tp25a1: 03 wifi1 !width warf" } +:do { /interface/wifi/set [find default-name=wifi1] !channel.band } on-error={ :log info "tp25a1: 04 wifi1 !band warf" } +:do { /interface/wifi/set [find default-name=wifi1] !channel.skip-dfs-channels } on-error={ :log info "tp25a1: 05 wifi1 !skipdfs warf" } +:do { /interface/wifi/set [find default-name=wifi2] !channel.width } on-error={ :log info "tp25a1: 06 wifi2 !width warf" } +:do { /interface/wifi/set [find default-name=wifi2] !channel.band } on-error={ :log info "tp25a1: 07 wifi2 !band warf" } +:do { /interface/wifi/set [find default-name=wifi2] !channel.skip-dfs-channels } on-error={ :log info "tp25a1: 08 wifi2 !skipdfs warf" } + +# --- Schritt 1: Fund D — Slave-VAP-Override weg ----------------------------- +:do { /interface/wifi/set [find name=w2-iot] !channel.width } on-error={ :log info "tp25a1: 09 w2-iot !width warf" } +:do { /interface/wifi/set [find name=w2-iot] !channel.band } on-error={ :log info "tp25a1: 10 w2-iot !band warf" } + +:log info ("tp25a1: wifi1-width=" . [:tostr [/interface/wifi/get [find default-name=wifi1] channel.width]] . " wifi2-width=" . [:tostr [/interface/wifi/get [find default-name=wifi2] channel.width]] . " w2iot-band=" . [:tostr [/interface/wifi/get [find name=w2-iot] channel.band]]) diff --git a/routeros/tp25-schritt1-3-ap2.rsc b/routeros/tp25-schritt1-3-ap2.rsc new file mode 100644 index 0000000..f7e4e2e --- /dev/null +++ b/routeros/tp25-schritt1-3-ap2.rsc @@ -0,0 +1,43 @@ +# TP25 Schritt 1-3 auf ap2 — Funkparameter nach Manual statt Bauchgefuehl. +# +# Schritt 1: unzulaessigen channel.*-Override von w2-iot entfernen (Slave-VAP +# kann keinen eigenen Kanal haben; auf ap1 erzwang er sogar 2ghz-n +# gegen einen 2ghz-ax-Master). +# Schritt 2: Inline-channel.*-Overrides auf wifi1/wifi2 leeren, damit die +# verlinkten Profile ch-5g/ch-2g ueberhaupt greifen. Das Override +# gewinnt sonst — deshalb lief 2,4 GHz auf 40 MHz, obwohl ch-2g +# width=20mhz sagt. +# Schritt 3: ch-5g auf 20/40mhz + Frequenz 5220 (Indoor-Band, statt 5745 +# ETSI-Band-C mit gedrosselter Leistung -> Messung s.u.). +# +# MESSZWECK: nach dem Deploy tx-power auf wifi1 lesen. Erwartung 18 dBm statt 9. +# Bestaetigt oder widerlegt die Diagnose "ch149 kostet 9 dB" AM GERAET. +# +# Push: python3 nautobot/gc-manual-plan.py --device ap2 \ +# --commands-file routeros/tp25-schritt1-3-ap2.rsc \ +# --change-id TP25-Funkparameter-ap2 --deploy +# Backup davor: ap2-pre-tp25-20260817.backup +# +# ⚠️ Wirft alle Clients kurz raus (Channel-/VAP-Re-Apply, bei TP3.3 gemessen). + +# --- Schritt 1: w2-iot Slave-Override weg ----------------------------------- +:do { /interface/wifi/set [find name=w2-iot] !channel } on-error={ :log info "tp25: 01 w2-iot !channel warf" } + +# --- Schritt 2: Inline-Overrides auf den Master-Radios weg ------------------ +# Nur channel.* wird geleert. configuration=/configuration.manager/.mode +# bleiben unangetastet — die sind korrekt und tragen die SSID-Bindung. +:do { /interface/wifi/set [find default-name=wifi1] !channel } on-error={ :log info "tp25: 02 wifi1 !channel warf" } +:do { /interface/wifi/set [find default-name=wifi2] !channel } on-error={ :log info "tp25: 03 wifi2 !channel warf" } + +# --- Schritt 3: Profile auf Manual-konforme Werte --------------------------- +# 5 GHz: 80 -> 40 MHz. Kostet Spitzendurchsatz, den hier niemand braucht, und +# gewinnt ~3 dB Randabdeckung. Erst 40 MHz macht zwei ueberlappungsfreie +# Zellen im Indoor-Band ueberhaupt moeglich (dort liegt nur EIN 80-MHz-Block). +:do { /interface/wifi/channel/set [find name=ch-5g] frequency=5220 width=20/40mhz } on-error={ :log info "tp25: 04 ch-5g warf" } + +# 2,4 GHz: Profil steht schon auf 20mhz — nach Schritt 2 greift es endlich. +# Zur Sicherheit explizit, damit der Sollzustand in der SoT eindeutig ist. +:do { /interface/wifi/channel/set [find name=ch-2g] frequency=2462 width=20mhz } on-error={ :log info "tp25: 05 ch-2g warf" } + +# --- Selbstprotokoll (Deploy-Job zeigt den Geraete-Output nicht) ------------ +:log info ("tp25ap2: ch-5g=" . [/interface/wifi/channel/get [find name=ch-5g] frequency] . "/" . [/interface/wifi/channel/get [find name=ch-5g] width] . " ch-2g=" . [/interface/wifi/channel/get [find name=ch-2g] frequency] . "/" . [/interface/wifi/channel/get [find name=ch-2g] width]) diff --git a/routeros/tp25-schritt2-fix-overrides-ap2.rsc b/routeros/tp25-schritt2-fix-overrides-ap2.rsc new file mode 100644 index 0000000..81da2a7 --- /dev/null +++ b/routeros/tp25-schritt2-fix-overrides-ap2.rsc @@ -0,0 +1,42 @@ +# TP25 Schritt 2 — KORREKTUR. Die Inline-Overrides sind noch da. +# +# 🔴 GOTCHA (2026-08-17 am Geraet belegt): `/interface/wifi/set !channel` +# loescht die Inline-Sub-Property-Overrides NICHT. Es wirft auch nicht — es +# tut einfach nichts Sichtbares. Nach dem Lauf stand auf ap2 wifi1 weiterhin +# `channel.width=20/40/80mhz`, obwohl das Profil ch-5g auf 20/40mhz steht +# und cfg-main-5g korrekt zu 20/40mhz aufloest. +# => Sub-Properties muessen EINZELN geleert werden: !channel.width usw. +# Gleiches Muster wie der bekannte `!configuration.ssid !security.*`-Griff +# aus dem TP3-Bring-up (CLAUDE.md) — dort nur nie auf channel.* angewandt. +# +# 🔴 DRINGLICHKEIT: weil die Breite noch auf 80 MHz stand, ist ap2 mit dem +# Frequenzwechsel auf 5220/eeCe in DENSELBEN 80-MHz-Block wie ap1 +# (5180/Ceee) gerutscht — beide belegen ch36-48. Das ist die Co-Channel-Lage, +# die TP3 2026-06-18 ueberhaupt erst wegkonfigurieren wollte. Diese Datei +# stellt den ueberlappungsfreien Zustand her. +# +# Push: python3 nautobot/gc-manual-plan.py --device ap2 \ +# --commands-file routeros/tp25-schritt2-fix-overrides-ap2.rsc \ +# --change-id TP25-Overrides-ap2 --deploy +# Backup: ap2-pre-tp25-20260817.backup gilt weiter. +# +# SOLL danach: wifi1 = 5220/ax/Ce/I (40 MHz, ch44+48), wifi2 = 2462/ax (20 MHz). + +# --- wifi1: jede Sub-Property einzeln leeren -------------------------------- +:do { /interface/wifi/set [find default-name=wifi1] !channel.width } on-error={ :log info "tp25f: 01 wifi1 !width warf" } +:do { /interface/wifi/set [find default-name=wifi1] !channel.band } on-error={ :log info "tp25f: 02 wifi1 !band warf" } +:do { /interface/wifi/set [find default-name=wifi1] !channel.skip-dfs-channels } on-error={ :log info "tp25f: 03 wifi1 !skipdfs warf" } + +# --- wifi2: dito. Danach greift ch-2g mit width=20mhz -------------------- +:do { /interface/wifi/set [find default-name=wifi2] !channel.width } on-error={ :log info "tp25f: 04 wifi2 !width warf" } +:do { /interface/wifi/set [find default-name=wifi2] !channel.band } on-error={ :log info "tp25f: 05 wifi2 !band warf" } +:do { /interface/wifi/set [find default-name=wifi2] !channel.skip-dfs-channels } on-error={ :log info "tp25f: 06 wifi2 !skipdfs warf" } + +# --- w2-iot: der eigentliche Fund D ---------------------------------------- +# Ein Slave-VAP darf keinen eigenen Kanal haben. Auf ap2 ist es nur width, +# auf ap1 zusaetzlich band=2ghz-n gegen einen 2ghz-ax-Master. +:do { /interface/wifi/set [find name=w2-iot] !channel.width } on-error={ :log info "tp25f: 07 w2-iot !width warf" } +:do { /interface/wifi/set [find name=w2-iot] !channel.band } on-error={ :log info "tp25f: 08 w2-iot !band warf" } + +# --- Selbstprotokoll: die AUFGELOESTEN Interface-Werte, nicht das Profil ---- +:log info ("tp25f: wifi1-width=" . [:tostr [/interface/wifi/get [find default-name=wifi1] channel.width]] . " wifi2-width=" . [:tostr [/interface/wifi/get [find default-name=wifi2] channel.width]] . " w2iot-width=" . [:tostr [/interface/wifi/get [find name=w2-iot] channel.width]])