Christoph Emsenhuber
8945f9ef53
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>
1.7 KiB
1.7 KiB