MikroTik wifi rulez: spektrum analízis CLI-ben

Minden WiFi eszközben helye lenne egy olyan tesztlehetőségnek, mint amilyet a MikroTik RouterOS-ben találtam. A szomorú valóság ezzel szemben az, hogy ilyesmi az Aruba cuccokon van, meg valami hasonló a Cisco AP-ken, de a legtöbb gyártó nem büszkélkedhet azzal, hogy a szabad felhasználású 2,4 Ghz-es illetve 5GHz-es tartományban spektrum analízist biztosítana.

Hogy mire jó ez? WiFi hibakeresésnél kiválóan használható az ugyanezekben a frekvenciatartományokban jelen lévő bármilyen fizikai jel kimutatására, aminek az egyéb WiFi eszközökön kívül lehet a forrása mikohullámú sütő, DECT telefon, autós riasztórendszer, rádiós kamerarendszer stb.

A MikroTik eszközökben - már amelyik támogatja ezt a lehetőséget, a RouterBoard 493-as történetesen ilyen - roppant egyszerű ennek a használata: interface wireless spectral-history wlan1:

Az itt látható rádiós környezetben például kiválóan megfigyelhető, hogy a 2437 MHz-es center frekvenciájú 6-os WiFi csatornára (2427-2447 MHz) nem érdemes jelet kitenni, sokkal jobbak a fizikai jel interferencia nélküli túlélésének esélyei az 1-es vagy a 11-es csatornán, igazán jól pedig a 13-as, vagy ha támogatják eszözeink, akkor 14-es csatornán érezné magát.

ISR router funkciók MikroTiken

Tesztelésre nálam van egy MikroTik eszköz (RouterBoard 493-as), 5.11-es RouterOS-szel, 9 darab tetszés szerint konfigurálható (Layer 2 / Layer 3) Ethernet interfésszel és egy WiFi interfésszel. Soha nem használtam még MikroTiket meg RouterOS-t korábban, egy picit irigykedve olvasgattam mások tapasztalatairól fórumokon, erre-arra, hogy ez linuxos cucc, mennyire megbízható, olcsóbb, mint a Cisco, ezt is tudja, azt is tudja.

Azért be kell vallanom, nem volt túl rózsás a kezdet, ugye a webes GUI meg a WinBox nevű windowsos konfiguráló csodák eleve nem is nagyon izgattak, hiszen ha használni fogunk MikroTiket, akkor az olyan környezetben lesz, ahol csak CLI jöhet szóba, és a CLI-t azt bizony szokni kell mondjuk egy IOS vagy bármi hasonló után. A hivatalos CLI dokumentáció sincs túl bő lére eresztve, úgyhogy MikroTik vonalon  sokat segít, ha az ember konzolkábelt ragad, és megpróbál mindenféle konfigurációkat összerakosgatni. Meglehet, hogy lesz még néhány hasonló poszt.

Elsőre arra gondoltam, hogy egy viszonylag általános ISR (Integrated Services Router) konfigurációt dobok össze: bridge a LAN portokon, SRC NAT, esetleg egy DNAT, WiFi (WPA2-PSK), WAN oldalon DHCP kliens, LAN oldalon DHCP szerver, NTP kliens... De még mielőtt belekezdenénk: a soros konzolport sebességét toljuk fel a terminálkliensünkön a sztenderd 9600-ról 115200-ra, ennél a típusnál ugyanis ez az alapértelmezés (gyors- és gépírók előnyben :)). A első dolog, amit érdemes beállítani, az a hostnév, itt persze véletlenül sem hostnévnek hívják:

/system identity
set name=TESZTROUTER

Jöhet a bridge interfész létrehozása. Fontos tudni, hogy ezen a boardon switch chip is van, így nem szoftverből történik a kapcsolás, hanem ASIC alapon megy, ami mindenképp dicséretes. A portok tetszőleges csoportját össze lehet bridge-elni, ebben a konfigurációban az ether1 porton kívül minden egyéb port a LAN oldali bridge groupban lesz:

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 disabled=no interface=ether2
add bridge=bridge1 disabled=no interface=ether3
add bridge=bridge1 disabled=no interface=ether4
add bridge=bridge1 disabled=no interface=ether5
add bridge=bridge1 disabled=no interface=ether6
add bridge=bridge1 disabled=no interface=ether7
add bridge=bridge1 disabled=no interface=ether8
add bridge=bridge1 disabled=no interface=ether9
add bridge=bridge1 disabled=no interface=wlan1

Adjunk a WAN és LAN oldali interfészeinknek címet, a WAN port az ether1 lesz, a LAN oldalon pedig a bridge1 interfész fogja kiszolgálni a klienseket:

/ip dhcp-client
add default-route-distance=1 disabled=no interface=ether1
/ip address
add address=10.100.202.1/24 disabled=no interface=bridge1

A következő lépés a DHCP szerver beállítása LAN oldalon. Ehhez létre kell hozni egy IP poolt, azt hozzárendelni egy DHCP szerverhez (TEST_DHCP_SRV), illetve egy interfészhez (bridge1). Csak alapinformációkat adunk át a klienseknek, a default gw és egy Google DNS IP minden, amit az IP címen kívül megkapnak egy félórára. Egy pici csavart azért vittem bele, hogy megnézzem a static (v. reserved) DHCP funkciót is, a 00:0C:42:B5:8C:48-as MAC című kliensünk mindig a 10.100.202.200-as IP címet fogja megkapni:

/ip pool
add name=TEST_DHCP_POOL ranges=10.100.202.200-10.100.202.254
/ip dhcp-server
add name=TEST_DHCP_SRV address-pool=TEST_DHCP_POOL disabled=no interface=bridge1 lease-time=30m
/ip dhcp-server network
add address=10.100.202.0/24 dns-server=8.8.8.8 gateway=10.100.202.1
/ip dhcp-server lease
add address=10.100.202.200 disabled=no mac-address=00:0C:42:B5:8C:48


Következzék a NAT beállítása: egyrészt szeretnénk a 10.100.202.0/24-ben lévő LAN oldali klienseket betenni SRC NAT mögé, másrészt a WAN IP-re érkező TCP 2323 kapcsolatokat DNAT-tal áttesszük az imént static DHCP-re állított LAN oldali host 23-as TCP portjára. Itt mind a SRC, mind a DST NAT esetében olyan parancsváltozatokat használtam, amelyekkel el lehet kerülni a külső IP-re való hivatkozást (mivel ebben a konfigurációban dinamikus a WAN IP-cím), de természetesen a RouterOS kelléktárában vannak ennél komolyabb NAT szabályokat is lehetővé tevő eszközök:

/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1
add action=dst-nat chain=dstnat disabled=no protocol=tcp dst-port=2323 to-port=23 to-addresses=10.100.202.200

Érdemes szinkronizálni a rendszer óráját valami közeli NTP szerverrel:

/system clock
set time-zone-name=Europe/Budapest
/system ntp client
set enabled=yes mode=unicast primary-ntp=148.6.0.1

Végül következhet a WiFi beállítása. Először egy biztonsági profilt kell létrehoznunk, amit utána rá lehet aggatni az SSID-nkre. A "TEST_PROFILE_WIFI" profil WPA2-PSK authentikációt használ és AES titkosítást, a profilt használó "TEST_MIKROTIK" SSID-t 802.11b, g és n szabványt ismerő klienseknek szórjuk az 1-es csatornán (2412 MHz):

/interface wireless security-profiles
add name=TEST_PROFILE_WIFI authentication-types=wpa2-psk group-ciphers=aes-ccm group-key-update=5m mode=dynamic-keys wpa2-pre-shared-key=12345678
/interface wireless
enable wlan1
set name=wlan1 mode=ap-bridge band=2ghz-b/g/n bridge-mode=enabled frequency=2412 hide-ssid=no security-profile=TEST_PROFILE_WIFI ssid=TEST_MIKROTIK

Ebben a formában a konfigurációnk még nem igazán internetképes, mindenféle biztonsági problémák lehetnek vele, alapból például fut a RouterOS-en a telnet szolgáltatás, tűzfalat is kellene konfigurálni, jelszót beállítani az admin usernek stb. de kezdetnek megteszi, a többit talán majd egy másik alkalommal.

A Babel routing protokoll

Épp az OpenWRT oldalán böngésztem a híreket (egyre türelmetlenebbül várom a tavalyi 10.3-as verzió frissítését), amikor olvasom, hogy holnapután Barcelona mellett lesz a "Wireless Battle Mesh v4". Hát az meg mi? No, nem mintha elmennék vagy ilyesmi, de sosem hallottam még csak hasonlóról sem, ezek meg már a negyediket rendezik...

Némi kutakodás után, bár sokkal okosabb nem lettem, arra jutottam, hogy ez valamiféle perverz geek találkozó, ahol tényleg foglalkoznak wifivel, de a hangsúly nem ezen van, hanem a routingon. Egy-egy ilyen esemény alkalmával összedobnak egy mesh hálózatot, amelyben minden egyes eszközön (a mesh gráf csúcsai) routeolás folyik és valamilyen irányító protokoll fut.

Itt jön a lényeg, hogy milyen protokollt érdemes választani? A rádiós hálózatok ugyanis a vezetékesekkel szemben számos meglepetést tartogathatnak. Változhat például a topológia az eszközök mozgatása, ki-be kapcsolása nélkül is, az épp aktuális rádiós viszonyok függvényében, és a vezetékes világban megszokott, gyakorlatilag kétállapotú összeköttetések (a mesh gráf élei) -- amelyek ugye vagy működnek vagy nem -- helyett előfordulhatnak olyan "működő" kapcsolatok, amelyek érdemi információtovábbításra nem alkalmasak, mert igen jelentős rajtuk a csomagvesztés.

A legizgalmasabb az egészben, hogy új irányító protokollokat tesztelnek és hasonlítanak össze egymással ezen a mesh hálózaton. Részt lehet venni bármilyen nyílt forrású implementációval, ami működőképes OpenWRT alatt. Az külön poén, hogy ilyenek tényleg vannak, a felhívás szerint ezen a negyedik mesh találkozón a Babel, a B.A.T.M.A.N., a BMX (B.A.T.M.A.N. Experimental) és az OLSR protokollok biztosan szerepelnek. Egy picit utánaolvastam mindnek, és találtam egy összehasonlító elemzést is, amely szerint a Babel a nyerő.

Ezek után a Babel doksit végig is nyálaztam, kiderült, hogy ez egy új távolságvektor-alapú protokoll, az említettek közül ez a legfiatalabb, kifejezetten mesh wifihez készült, de állítólag vezetékes környezetben is megállja a helyét. A  teljesség igénye nélkül a protokoll néhány fontosabb jellemzője:

• A Babel által használt metrika a prokollt futtató szomszédos eszközök közötti kommunikációra épül, az eszközök Hello üzeneteket küldenek szomszédaiknak, amelyekre azok az "I Heard You" (IHU) választ kapják. Az üzenetváltások sikeressége alapján a babeles eszköz költséget számol minden egyes szomszédjához, értelemszerűen a költség annál kisebb, minél kevesebb a sikertelen üzenetváltás.
• A protokoll alapvetően a Bellman-Ford algoritmusra épít (periodikus frissítések minden szomszédtól és ezen frissítések alapján a legalacsonyabb költségű útvonal kiválasztása, illetve a végtelenig számlálás), bizonyos megszorításokkal.
• Ilyen megszorítás, hogy egy adott router nem vesz tudomást egy másikhoz vezető  frissítésekről, amíg azok kisebb költségűek, mint a rajta nyilvántartott eddigi legkisebb költség az adott célhoz (a nagyobb költségűeket pedig épp azért hagyja figyelmen kívül, mert ott nagyobb a költség, így nem éri meg átváltani rájuk).
• Az előző pont, bár megakadályozza a hurkok kialakulását, a topológia módosulásakor route-ok használhatatlanná válásához vezet, ezért a Babel által küldött frissítésekben szekvenciaszámok is szerepelnek, és egy frissítés átmegy a szűrőn, ha a szekvenciaszám nagyobb, mint az eddig látott szekvenciaszám.
• A szekvenciaszám növelését kérhetik is a routerek egymástól, minden routernek saját szekvenciaszáma van. A szekvenciaszám-növelési kérelmek jelentősen felgyorsítják a konvergenciát.
• Ha azonos prefixet meghirdet több eszköz is, akkor azokat a prefixeket a Babel külön entitásként kezeli, vagyis mindenki a hozzá "közelebbi" forrást fogja használni.
• Támogatja az IPv4-et és az IPv6-ot is.

Gyaníthatóan ez a kis összegzés több kérdést vet fel, mint amennyit megválaszol, a végső válaszok a protokoll dokumentációjában érhetők el.

Szeretem a Cisco AP-k carrier busy tesztjét

Régóta keresgélek alternatívát az autonóm Cisco AP-k IOS-ében rendelkezésre álló carrier busy tesztre. Na jó, talán még a keresgélek használata is túlzás, mondjuk úgy, hogy időnként elszontyolodom, hogy nincs (vagy nem tudok) hasonló dologról például a notebookomra, vagy mondjuk Androidra. Valami egyszerű kis parancssoros util megtenné, amivel gyorsan, könnyen lehet felmérni a teljes wifi tartomány layer1-es kihasználtságát.

A félreértések elkerülése végett: nem wifi analyzert keresek, ami grafikonokat rajzolgat az elérhető SSID-kről, csatornákról, és azokat tudja ilyen vagy olyan szempontok szerint rendezgetni, nem. A carrier busy teszt az IOS-ben ennél sokkal alapvetőbb, a fizikai rétegre vonatkozó teszt, ami azt vizsgálja meg, hogy van-e bármilyen, az AP rádióvevője számára érzékelhető forgalom a szabad frekvenciatartományban. Ez aztán lehet persze a szomszéd wifije, de lehet mikrosütő, rádiós kamerarendszer, vezeték nélküli telefon, bármi, ami interferálhat a wifi jelekkel. Ezzel a carrier busy teszttel tehát megállapítható, hogy az adott pillanatban van-e az adott AP környékén zavaró jelforrás, ami tönkre vághatja a wifi kommunikációt. Annyira nem részletes mint egy komplett spektrum analízis, de jól használható és a CLI elég hozzá.

Aki esetleg nem ismerné ezt a tesztet: a "dot11 <interfész> carrier busy" paranccsal futtatható, és mindössze néhány másodpercig tart, míg végigszkenneli a frekvenciatartományt. A parancs kiadásakor az AP-n természetesen minden kiépített wifis kapcsolat megszakad, az adott AP-n lógó klienseknek újra kell majd authentikálniuk stb. A lefutás után látszólag nem történik semmi, de a teszt eredményét a "show dot11 carrier busy" paranccsal egyetlen egyszer meg tudjuk jeleníteni. A példában látható, hogy nem egy rádiószmogos környéken lakik a teszt AP, a 6-os channelen valami csordogál (2427-2447), de például az 1-es (2402-2422) vagy a 11-es (2452-2472) nagyjából kihasználatlannak tűnik:

AP#dot11 dot11Radio 0 carrier busy
AP#show dot11 carrier busy       

Frequency  Carrier Busy %
---------  --------------
   2412          0
   2417          1
   2422          1
   2427          3
   2432          6
   2437          4
   2442          2
   2447          2
   2452          0
   2457          0
   2462          1
   2467          0
   2472          0
AP#show dot11 carrier busy
AP#

A "show dot11 carrier busy" ismételt használata semmilyen eredményt nem ad egészen addig, amíg meg nem ismételjük a carrier busy tesztet, ekkor az új eredményt - szintén csak egyszer - listázza. Nem egy spektrum analízis, de legtöbbször ennyi is megteszi. No, valami ilyesmit keresek időnként Linuxra, Windowsra vagy Androidra, és eddig még nem találtam.