TP28: WLAN laeuft ueber CAPsMAN auf crs326-core — beide APs sind reine CAPs

Der Methodenwechsel ist vollzogen. Beide hAP ax2 sind CAPs, die gesamte
WLAN-Konfiguration liegt auf dem Core: 4 Kanaele, 6 Datapaths, 6 Security,
2 Steering, 9 Configurations, 4 Provisioning-Regeln je radio-mac.

Warum es diesmal traegt, obwohl CAPsMAN 2026-07-22 abgeschafft wurde: damals
war ap1 Manager UND AP, und ein Manager kann seine eigenen Radios nicht per
CAPsMAN provisionieren — genau diese Asymmetrie war die Ursache von TP3.1.
Mit dem Core als Manager sind beide APs symmetrisch. Der Core braucht dafuer
kein wifi-qcom: das capsman-Menue steckt im Basis-routeros, die 3,35 MB
freier Flash sind irrelevant.

Verifiziert am Geraet: beide remote-caps "Ok", alle 7 dynamischen VAPs je AP
mit korrekter SSID und VLAN, Kanaele exakt wie in TP25 gemessen (ap1
5180/ax/Ce/I + 2412/ax, ap2 5220/ax/Ce/I + 2462/ax), Bridge-Ports mit
richtigen PVIDs. "traffic processing on CAP" bestaetigt Local-Forwarding —
im neuen /interface/wifi gibt es ohnehin kein zentrales Forwarding mehr,
die datapath-Property existiert deshalb nicht.

ft-over-ds=yes ist jetzt aktiv (unter CAPsMAN erstmals verfuegbar), und
dirtyvader-guest hat eigenes Steering mit neighbor-group=bf-guest — nicht
bf-main mitbenutzt, sonst meldet 802.11k Gast-Clients BSSIDs einer SSID,
auf die sie nicht assoziieren koennen.

🔴 routeros/.secrets/wlan-psks.env war fuer infra/iot/untrusted VERALTET.
Die laufenden PSKs standen in ap1-prov-base.rsc. Mit den Datei-Werten
konnten die Shellys sich nicht mehr anmelden. Datei auf den laufenden Stand
korrigiert, PSKs auf dem Manager nachgezogen. Wer die Datei blind als
Wahrheit nimmt, sperrt das halbe IoT-Netz aus.

🔴 Eigener Messfehler, festhalten: /interface/wifi/registration-table auf dem
CAP zeigt unter CAPsMAN NICHTS. Die Registrierungen fuehrt der MANAGER.
Ich habe daraus faelschlich "WLAN ist unten" geschlossen, waehrend Christophs
Geraete mit vollem Ausschlag verbunden waren. Ab jetzt nur noch am Manager
zaehlen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

routeros/tp27-routerboot-firmware-724.rsc

@@ -0,0 +1,37 @@
+# TP27 — RouterBOOT-Firmware auf 7.24 nachziehen (2026-08-17).
+#
+# KONTEXT: Christoph hat alle vier MikroTik selbst auf RouterOS 7.24 stable
+# gehoben. Verifiziert, nichts kaputt. Was dabei offen blieb, ist die zweite
+# Haelfte jedes MikroTik-Upgrades: die **RouterBOOT-Firmware** haengt zurueck.
+#
+#   crs326-core    7.19.5 -> 7.24
+#   crs326-branch  7.19.5 -> 7.24
+#   ap1            7.23.2 -> 7.24
+#   ap2            7.23.2 -> 7.24
+#
+# `/system routerboard upgrade` SCHREIBT die Firmware nur; wirksam wird sie
+# erst beim naechsten Reboot. Darum: erst schreiben, dann gezielt rebooten,
+# dann `current-firmware` gegenpruefen — vorher zeigt sie weiter den alten Wert.
+#
+# WARUM UEBER GC UND NICHT MikroMCP: `/system routerboard upgrade*` steht auf
+# der MikroMCP-Deny-Liste (zu Recht — es schreibt den Bootloader). Der
+# GC-Weg ist ohnehin der vorgeschriebene.
+#
+# Push je Geraet:
+#   python3 nautobot/gc-manual-plan.py --device <name> \
+#       --commands-file routeros/tp27-routerboot-firmware-724.rsc \
+#       --change-id TP27-fw-<name> --deploy
+#
+# Danach Reboot (MikroMCP `reboot`), dann:
+#   current-firmware muss 7.24 sein.
+#
+# REIHENFOLGE (bewusst): ap2 -> ap1 -> core -> branch.
+# branch zuletzt, weil der Arbeitsplatz per LAN daran haengt — er ist die
+# Lifeline zu allen anderen Geraeten und wird erst angefasst, wenn der Rest
+# nachweislich sauber oben ist.
+#
+# Backups davor: <geraet>-post724-pre-fw-20260817.backup
+
+:do { /system routerboard upgrade } on-error={ :log info "tp27: upgrade warf" }
+
+:log info ("tp27: fw-geschrieben current=" . [/system/routerboard/get current-firmware] . " upgrade=" . [/system/routerboard/get upgrade-firmware] . " (current wechselt erst nach dem Reboot)")