Rozhodol som sa nahradiť svoj Chateau 5G ax za hEX PoE, ktorý som mal pohodený bokom. Chateau mi dobre slúžil na predchádzajúcom mieste, kde nebolo rozumne cenové káblové pripojenie, takže 5G na SIM karte bolo cestou. Ale po presťahovaní som získal skvelú optiku a 5G modem sa stal zbytočným. Tiež som si postavil nový rack a Chateau so všetkými svojimi anténami trčiacimi von nie je práve rackový druh — musel ísť preč. hEX PoE sa naproti tomu pekne zmestí do racku, má PoE výstupy, ktoré som naozaj potreboval na napájanie mojich wAP ax prístupových bodov a PoE smart zvončeka, a celkovo to jednoducho dávalo väčší zmysel. Nie je to vlastne upgrade čo sa výkonu týka, ale ten som aj tak nevyužíval naplno. O Chateau a jeho Wi-Fi zvláštnostiach som písal v článku Wi-Fi ACL na RouterOS 7.

S odstráneným Chateau by všetky Wi-Fi siete obsluhovali wAP ax jednotky riadené centrálne cez CAPsMAN. Zámer je jednoduchý: dve SSID (hlavná a hosťovská) na pásmach 2.4GHz aj 5GHz, čo dáva 4 bezdrôtové siete na jeden prístupový bod. Realita bola ale ďaleko od jednoduchej a zabralo mi to celý večer.

Nastavenie #

hEX PoE (RB960PGS) funguje ako router a CAPsMAN kontrolér. Nemá vlastné Wi-Fi rádiá, ale dokáže spravovať vzdialené rádiá cez balík wifi. Dve jednotky wAP ax sa zapojia do jeho PoE portov a cez jeden kábel dostanú napájanie aj sieť. Konfigurácie mám uložené vo verziovacom systéme vďaka môjmu zálohovaciemu postupu, čo výrazne uľahčilo riešenie problémov.

CAPsMAN konfigurácia pozostáva z dvoch konfigov a dvoch provisionovacích pravidiel:

/interface wifi configuration
add channel.skip-dfs-channels=10min-cac country=Slovakia datapath.bridge=\
    bridge1 disabled=no name=cfg1 security.authentication-types=wpa2-psk \
    .ft=yes .ft-over-ds=yes .passphrase=SECRET ssid=MojaSiet
add country=Slovakia datapath.bridge=bridge1 .traffic-processing=on-cap \
    .vlan-id=10 disabled=no name=cfg2 security.authentication-types=wpa2-psk \
    .ft=yes .ft-over-ds=yes .passphrase=SECRET ssid=HostovskaSiet

/interface wifi provisioning
add action=create-dynamic-enabled master-configuration=cfg1 \
    slave-configurations=cfg2 supported-bands=2ghz-ax
add action=create-dynamic-enabled master-configuration=cfg1 \
    slave-configurations=cfg2 supported-bands=5ghz-ax

Keď sa wAP ax pripojí a jeho CAP režim objaví CAPsMAN kontrolér, každé z jeho dvoch rádií by malo byť zachytené provisionovacími pravidlami. Pre každé rádio CAPsMAN vytvorí master rozhranie s cfg1 (hlavná sieť) a slave rozhranie s cfg2 (hosťovská sieť na VLAN 10). Dve rádiá krát dve konfigurácie sa rovná štyri siete. To je teória. V praxi som neustále dostával len tri.

Problém 1: zastarané interné ID v provisionovacích pravidlách #

Toto bol ten najpodlejší. Keď v RouterOS odstránite a znovu vytvoríte konfiguráciu, dostane nové interné ID. Ale provisionovacie pravidlá, ktoré odkazovali na starú konfiguráciu, naďalej ukazujú na staré ID. Vidieť to vo výstupe:

/interface wifi provisioning print detail

0   supported-bands=2ghz-ax action=create-dynamic-enabled
    master-configuration=cfg1 slave-configurations=*2

1   supported-bands=5ghz-ax action=create-dynamic-enabled
    master-configuration=cfg1 slave-configurations=*2

Všimnite si slave-configurations=*2 namiesto slave-configurations=cfg2. *2 bolo interné ID konfigurácie, ktorá už neexistovala. CAPsMAN spokojne vytvoril slave rozhrania, ale nemali za sebou žiadnu skutočnú konfiguráciu:

cap-wifi1-virtual1  cap-wifi1  Hostia

Komentár na tomto rozhraní hovoril SSID not set, hoci v stĺpci konfigurácie zobrazoval SSID hosťovskej siete. Opravou bolo znovuvytvorenie provisionovacích pravidiel:

/interface wifi provisioning remove [find]
/interface wifi provisioning add action=create-dynamic-enabled \
    supported-bands=2ghz-ax master-configuration=cfg1 \
    slave-configurations=cfg2
/interface wifi provisioning add action=create-dynamic-enabled \
    supported-bands=5ghz-ax master-configuration=cfg1 \
    slave-configurations=cfg2

Po tomto sa v provisionovacích pravidlách zobrazilo cfg2 podľa mena namiesto zastaraného odkazu *2.

Problém 2: zmiešané režimy spracovania prevádzky #

S opraveným provisionovacími pravidlami sa objavil 2.4GHz slave, ale zobrazil znepokojivú správu:

operated by CAP F4:1E:57:XX:XX:XX%bridge1, traffic processing on CAPsMAN (no encryption)

Časť “no encryption” bola alarmujúca. Ukázalo sa, že cfg1 (hlavná sieť) predvolene používal traffic-processing=on-cap, zatiaľ čo cfg2 (hosťovská sieť) bol explicitne nastavený na traffic-processing=on-capsman. Tento zmiešaný režim, kde master rozhranie spracováva prevádzku lokálne na CAP-e, ale slave ju tuneluje späť na kontrolér, spôsobil nesprávne zobrazenie stavu šifrovania.

Nastavenie oboch na rovnaký režim to opravilo:

/interface wifi configuration set cfg2 datapath.traffic-processing=on-cap

Komentár sa potom zmenil na jednoduché:

operated by CAP F4:1E:57:XX:XX:XX%bridge1, traffic processing on CAP

Žiadna správa “no encryption”.

Problém 3: DFS blokujúci 5GHz slave #

Aj po oprave prvých dvoch problémov zostal 5GHz slave (cap-wifi2-virtual1) neaktívny. Pohľad na zoznam CAPsMAN rozhraní odhalil príčinu:

cap-wifi2            MDB   DFS channel availability check (10 min)
cap-wifi2-virtual1   DBI

5GHz master uviazol v kontrole dostupnosti DFS kanálu. Na strane CAP-u rádio v skutočnosti normálne fungovalo na kanáli 5500, ale CAPsMAN si myslel, že DFS kontrola stále prebieha, a odmietol vytvoriť slave virtuálne rozhranie.

Chateau mal na svojom lokálnom 5GHz rádiu nastavené channel.skip-dfs-channels=10min-cac, ale toto nastavenie nebolo prítomné v cfg1, čo je CAPsMAN konfigurácia posielaná na vzdialené rádiá. Pridanie bolo opravou:

/interface wifi configuration set cfg1 channel.skip-dfs-channels=10min-cac

Po re-provisionovaní sa DFS kontrola dokončila za 1 minútu namiesto toho, aby uviazla, a všetky štyri rozhrania sa spustili:

cap-wifi1            Bezdrotova-siet   MDB
cap-wifi1-virtual1   Hostia             DB
cap-wifi2            Bezdrotova-siet   MDB
cap-wifi2-virtual1   Hostia             DB

Strana wAP ax #

Pre úplnosť, CAP konfigurácia na každom wAP ax je minimálna. CAPsMAN kontrolér sa stará o všetko, prístupový bod potrebuje len vedieť, kde ho nájsť:

/interface bridge
add admin-mac=04:F4:1C:XX:XX:XX auto-mac=no name=bridgeLocal vlan-filtering=yes
/interface wifi datapath
add bridge=bridgeLocal name=capdp
/interface wifi
set [ find default-name=wifi1 ] configuration.manager=capsman \
    configuration.mode=ap datapath=capdp disabled=no
set [ find default-name=wifi2 ] configuration.manager=capsman \
    configuration.mode=ap datapath=capdp disabled=no
/interface bridge port
add bridge=bridgeLocal interface=ether1
add bridge=bridgeLocal interface=ether2
/interface bridge vlan
add bridge=bridgeLocal tagged=bridgeLocal,ether1 vlan-ids=10
add bridge=bridgeLocal untagged=ether1,ether2 vlan-ids=1
/interface wifi cap
set discovery-interfaces=bridgeLocal enabled=yes
/ip dhcp-client
add interface=bridgeLocal

Bridge potrebuje VLAN 10 tagované, pretože hosťovská sieť používa traffic-processing=on-cap s vlan-id=10. CAP spracováva hosťovskú prevádzku lokálne a posiela ju tagovanú cez trunk na kontrolér, kde sa smeruje do hosťovského VLAN-u.

Ponaučenia #

Tri samostatné problémy sa spojili a vytvorili niečo, čo vyzeralo ako jeden problém “fungujú len 3 zo 4 sietí”. Každá oprava bola nutná, ale sama o sebe nestačila:

  1. Keď znovu vytvoríte CAPsMAN konfiguráciu, vždy znovu vytvorte aj provisionovacie pravidlá, inak budú naďalej odkazovať na zastarané interné ID
  2. Nemiešajte režimy traffic-processing medzi master a slave konfiguráciami na rovnakom rádiu
  3. Ak CAPsMAN kontrolér spravuje rádiá na DFS kanáloch, nastavte channel.skip-dfs-channels v CAPsMAN konfigurácii, nielen na lokálnych rozhraniach

Nenašiel som nič z toho zrozumiteľne zdokumentované na jednom mieste, tak dúfam, že toto niekomu ušetrí večer, ktorý som tým strávil. Užívajte!

Odkazy #