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>
hAP ax² Setup — CAPsMAN + VLAN (Design & Plan, REVIEW vor Apply)
Stand: beide auf RouterOS 7.23.1 + RouterBOOT 7.23.1. Namen/IPs gesetzt: ap1 = 10.40.41.1 (künftiges Gateway/Router) · ap2 = 10.40.41.2 (CAP). Default-Bridge (ether2–5+wifi, vlan-filtering aus).
⚠️ Status: NUR PLAN. An den Geräten bisher nur: Firmware 7.23.1, Identity ap1/ap2, Stray-IP weg, Mgmt-IP→.1/.2. Exakte 7.23-Syntax (wifi/capsman/provisioning/scheduler) wird vor Apply gegen das Gerät validiert.
Hardware-Realität
- WiFi 6 (ax), dual-band 2,4+5 GHz. MLO ist NICHT verfügbar (MLO = WiFi 7/802.11be → bräuchte hAP be³). „MLO wenn möglich" entfällt.
Rollen
- ap1 = CAPsMAN-Manager + AP (später zusätzlich Router — L3/DHCP/DNS/NAT/CAKE = separater Cutover, NICHT hier).
- ap2 = CAP (zieht Wireless-Config von ap1 @ 10.40.41.1).
⚠️ Topologie / Verkabelung (Klärungsbedarf)
- ap1 → Core-Switch Port 2 (direkt). ✓ Guter Trunk-Kandidat.
- ap2 → hinter TP-Link TL-SG108E → Core-Switch Port 8. Damit ap2 die VLANs getaggt bekommt, müsste auch der TP-Link trunken (kann 802.1Q, aber fummelige UI). Empfehlung: ap2 im Wartungsfenster direkt an einen freien Core-Port (z.B. Port 3) → sauberer Trunk, keine TP-Link-VLAN-Config.
- ether1 = WAN — Achtung: Für ap1 (Router) ist ether1 = WAN zur FB (Internet); der LAN-Trunk zum Core bleibt ether2 → ap1 braucht 2 Kabel. Für ap2 (reiner AP) gibt es kein WAN; ein Uplink (Trunk) genügt. → Den LAN-Trunk auf ether1 zu legen wäre für den Router falsch. Finale Verkabelung bitte bestätigen.
Bridge-VLAN-Layout (beide APs)
- Uplink ether2 = Trunk: tagged
10,20,30,40,90,99,100+ native/untagged vlan1 (= aktuelles Mgmt-Netz, .1/.2). - Mgmt bleibt erreichbar (untagged vlan1), solange der Switch-Port native vlan1 untagged bleibt.
vlan-filtering=yeszuletzt — mit Auto-Rollback (5 min) gegen Lockout.
WLAN (SSID → VLAN via CAPsMAN-Datapath)
| SSID | VLAN | Security |
|---|---|---|
BF-Main |
10 (MAIN) | WPA3-only |
BF-IoT |
30 (IOT) | WPA2/WPA3-PSK |
BF-Guest |
90 (GUEST) | WPA2/WPA3-PSK |
Beide Bänder (2,4+5 GHz ax). Temp-Passphrase (Platzhalter BFtest-2026-tmp) — User setzt echte in Ruhe. |
VLAN-SSIDs bekommen erst nach dem Router-Cutover DHCP/Gateway. Sofort-Test optional via Temp-SSID auf native vlan1 (FB-DHCP).
Apply-Reihenfolge (wenn freigegeben)
- Switch: AP-Uplink-Port(s) → Trunk (tagged 10,20,30,40,90,99,100 + native vlan1). [ap2 erst sinnvoll, wenn direkt am Core ODER TP-Link trunkt]
- ap1: Bridge-VLAN → CAPsMAN-Manager → (Auto-Rollback) vlan-filtering=yes.
- ap2: Bridge-VLAN → CAP enable (manager=10.40.41.1).
- Verifizieren: ap2 im Manager; SSIDs auf beiden Radios; Mgmt erreichbar. Rollback canceln.
Safety — Auto-Rollback
/system scheduler add name=vlan-rollback interval=5m \
on-event="/interface bridge set [find name=bridge] vlan-filtering=no; /system scheduler remove vlan-rollback"
Offene Punkte (User)
- Finale Verkabelung bestätigen (ap1: ether1→FB-WAN, ether2→Core-Trunk; ap2: direkt an Core vs. TP-Link trunken).
- Switch-Mgmt-IP:
.3oder.239(da.2jetzt = ap2). - Echte WLAN-Passphrasen (später).
Dateien
routeros/ap1-manager.rsc·routeros/ap2-cap.rsc