TP5 Etappe 2 ausgerollt + TP25/TP16.3 angelegt, TP25 Schritte 1-3 durch

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 <noreply@anthropic.com>

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 <if> !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]])