František Ryšánek [ rysanek AT fccps DOT cz ]
Wifi je technologie určená pro bezdrátový přenos dat lokální sítě (LAN) - je přímo kompatibilní s Ethernetem, řeší přenos ethernetových rámců vzduchem. Tuto technologii popisuje rodina norem IEEE 802.11. Různá písmenka na konci za jedenáctkou řeší různé dílčí oblasti, nebo popisuje různé varianty modulace.
Původním účelem wifi bylo rozvést lokální síť v místnosti nebo budově bez nutnosti tahat kabely. Poměrně záhy ji uživatelé začali nasazovat také v exteriéru, na spoje "bod-bod" i na vykrytí určité oblasti (pro připojení více klientů k jednomu venkovnímu AP).
Rádiové spektrum je omezené a dosažitelná přenosová kapacita v rámci rádiového kanálu závisí na rušení, odstupu signál-šum a dalších analogových parametrech rádiového kanálu (základní fyzika platí pro každého). Proto kapacity WiFi nedrží krok 1:1 s dnešními metalickými a optickými sítěmi. WiFi zcela racionálně pracuje s proměnlivou modulační rychlostí, která se na konkrétní asociaci klient-AP automaticky přizpůsobuje poměrům v rádiovém přenosovém kanálu.
Síť WiFi je navržena jako polo-duplexní, stanice v rámci nakonfigurované
sítě sdílejí společný jediný kanál (kolizní médium) a pro úspěšný přenos
je třeba, aby vysílala v každém okamžiku pouze jedna stanice. Kdo nevysílá,
ten mlčí a naslouchá.
Používá se CSMA protokol zvaný CSMA/CA - podobnost s protokolem CSMA/CD
z metalického ethernetu je zřejmá, "aloha" zde vyvstává podobně, rozdíl je
pouze ve způsobu detekce kolizí: zatímco metalický half-duplexní transceiver
má možnost kolizi přímo detekovat na fyzickém médiu, rádio tuto možnost
v zásadě nemá (rozdíl mezi vysílaným a přijímaným výkonem je příliš velký).
Proto WiFi používá potvrzování (ACK) a opakování přenosu přímo v rámci
vrstvy L2, per packet. Zároveň se v "naslouchajícím" stavu snaží sledovat
provoz na svém kanálu a s vysíláním čeká na moment, kdy "zavládne ticho"
(což je shodné s metalickým ethernetem).
Reálně lze vytáhnout z WiFi kanálu obvykle cca polovinu jeho jmenovité
(navázané) bitové rychlosti. Je to patrně důsledek half-duplexního
provozu s per-packet ACKováním.
Existují proprietární varianty WiFi, které čas v rádiovém kanálu přidělují
mechanismem TDMA a/nebo neACKují každý paket zvlášť a/nebo provozují plný
duplex na dvou oddělených rádiových kanálech. V těchto uspořádáních se
nevyskytuje "aloha" a je možno dosáhnout lepší reálné průchodnosti v poměru
k dostupnému jmenovitému bitrate.
Pokud pomineme ad-hoc režim a WDS, probíhá přímá rádiová komunikace vždy
mezi centrálním nadřízeným uzlem zvaným Access Point, a podřízeným uzlem
zvaným Client (zvaným též "station"). Protokol neumožňuje klientům v tomto
tzv. "managed" režimu bavit se spolu v rádiovém kanálu přímo navzájem
- vzájemná komunikace klientů musí probíhat prostřednictvím AP.
Jednotliví klienti se na konkrétní AP napřed "asociují", aby poté mohli
v dané síti (řízené daným APčkem) vysílat a přijímat data.
AP vysílá na své nosné frekvenci pravidelné krátké oznámení zvané
"beacon". Tato režijní zpráva říká klientům "já jsem tady a servíruji
takovouto síť" (několik parametrů - jméno, autentikace/šifrování apod.).
Rádiové spektrum je omezené. Zejména v pásmu 2.4 GHz je kanálů malý počet, přitom právě v pásmu 2.4 GHz funguje převážná většina dnes používaných wifi zařízení (i dalších ne-WiFi rádií - ať to zjednodušíme, nebudeme zde uvažovat nic než wifi). Velmi snadno se tedy stane, že na jednom kanálu vysílá více AP, které jsou navzájem dost blízko na to, že se vidí. Při slabém provozu to není problém, prostě to funguje. Beacon je krátký, APčka se statisticky prostřídají, klienti vidí beacony od více AP na sdíleném kanálu a asociují se podle ESSIDu na "svoje" AP, v případě navíc i shodného ESSIDu obvykle na AP s nejsilnějším signálem.
Klasickým problémem je třeba situace, kdy operátor kabelové televize nebo ADSL dodává určitou značku a model CPE modemů s podporou WiFi, a v bytovce se sejde víc takových zařízení, přičemž jejich uživatelé jsou snad ještě dost osvícení na to, aby nasadili šifrování, ale kanál je takové zbytečné číslo, které nikdo moc neřeší (funguje to v defaultu) - takže máte na většině kanálů prázdno, ale na defaultním kanálu 1 je přecpáno (a vysílaný výkon si taky málokdo omezí).
Nebo Vám pásmo může být těsné v případě, že potřebujete "nasvítit" větší budovu nebo areál. Třeba ani nemáte rušící sousedy, jste v éteru široko daleko sami, ale při potřebném počtu AP se sdílení kanálů prostě nevyhnete.
Provoz na sdíleném kanálu je dokonce nutností v případě, že stavíte
pro rozsáhlejší vykrytí síť několika AP ve WDS režimu, kde APčka fungují
jako čistě rádiové repeatery. V tom případě potřebuje spolu navzájem
komunikovat několik AP, které mezi sebou navazují asociace "AP to AP"
- a protože jedno WiFi rádio vysílá zásadně na jediné nosné frekvenci
(v jednom kanálu), budou APčka ve WDS režimu kanál z principu sdílet.
Pozn.: režim WDS má potažmo nectnosti (např. omezenou kapacitu v rámci
kanálu), kvůli kterým je vhodné se mu pokud možno vyhnout, zejm. pokud
potřebujete z rádiového segmentu vyždímat maximální průchodnost.
V tom případě lze osadit jeden router více rádii (na více kanálech),
síť strukturovat hierarchicky, na konkrétním AP data forwardovat
mezi několika kanály.
Technologie WiFi je standardizována ve dvou bezlicenčních pásmech okolo 2.4 a 5.2-5.8 GHz. Každé pásmo je pro potřeby WiFi rozděleno do několika frekvenčních kanálů, tradičně o šíři 20 MHz. Pokud to ale hardware rádií podporuje, lze nakonfigurovat také užší nebo naopak širší kanál. Dnes běžná rádia 802.11n umí kanál široký 20 nebo 40 MHz, nastupující standard 802.11ac udává podporu kanálů o šířce 80 a 160 MHz. Naopak stávající MiniPCI-e rádia Atheros podporují i užší kanály o šířce 5 nebo 10 MHz = jemnější rastr v rámci dostupného pásma, což lze využít pokud potřebujete větší počet AP bez překryvů v rádiovém pásmu a nevadí Vám nižší kapacita kanálu (tohle musí umět také firmware AP a ovladače na klientu, třeba Mikrotik RouterOS to podporuje).
Čili jedním z úkolů při konfiguraci AP je zvolit pokud možno volný
frekvenční kanál. Zjistit blízké vysílače a jejich síly signálu lze buď
vlastními prostředky access-pointu, nebo lze použít softwarový scanner
na PC (např. Metageek Inssider) a k němu vhodnou WiFi síťovku
s koaxiálním portem pro externí anténu.
Access-pointy s "uživatelsky přítulnějším" konfiguračním rozhraním
obvykle v konfiguraci používají spíš pořadové číslo kanálu v rámci pásma
v klasickém rastru 20 MHz, spíš než jmenovitou nosnou frekvenci.
Pokud konfigurujete pouze klienta (nakonfigurovaný AP je Vám "shůry dán"), nemusíte kanál řešit - klient si proskenuje pásmo a chytí se na zadaný ESSID. Při ztrátě signálu skenování opakuje. Vlastně ho opakuje průběžně, aby případně mohl včas provést roaming na silnější AP se stejným ESSIDem.
Různé státy mají bezlicenční pásma okolo 2.4 a 5-6 GHz různě rozsáhlá. Národní frekvenční plán má obvykle na starosti nějaký státní úřad, který dohlíží na telekomunikace a elektromagnetickou kompatibilitu zařízení - tj. v našem případě ČTÚ.
Aby byla WiFi rádia snadno použitelná v různých státech světa, obsahuje jejich firmware obvykle tabulku frekvenčních plánů (povolených kanálů či frekvencí) pro různé státy světa. Uživatel pouze zvolí svůj stát ("country") a WiFi zařízení mu pak omezí množinu konfigurovatelných kanálů tak, aby nehrozilo vysílání mimo přidělené bezlicenční pásmo.
Na tomto místě se sluší napovědět, že ve vanilkovém Linuxu se stará o
národně-specifické nuance frekvenčních plánů zvrhlost zvaná CRDA,
která žije napůl v kernelu a napůl v user space, komunikuje skrz
UDEV a chová se obvykle zcela nevyzpytatelně a nepřátelsky.
Jejím typickým projevem je, že Vám neumožní zprovoznit rádio
v režimu AP prakticky na žádném kanálu - a není z toho snadná
cesta ven. (Klientský režim je obvykle bez problému.)
Framework CRDA bohužel převzaly i novější verze OpenWRT.
Naopak proprietární firmwary, byť založené na linuxu, mají CRDU
vyřazenou a nastavení "Country" je zcela lidské a pochopitelné.
Existuje také možnost použít "interní" kernelovou regulatory databázi
- tu je ale třeba zvolit při kompilaci kernelu (a dohlédnout na
aktuálnost zakompilované regulatory databáze).
Jedná se o textový řetězec, který si správce AP může zvolit prakticky libovolně. Někdo dává přednost anonymní zkratce, která pokud možno nepoukáže na identitu provozovatele AP. Jindy je vhodné, použít jako ESSID název firmy, případně lze použít třeba i e-mailovou adresu (ohleduplný přístup pro případ, že byste někoho rušili).
Síť lze provozovat i bez šifrování, pak je ale snadno napadnutelná
(odposlouchávatelná). Historicky vzniklo pro WiFi několik šifrovacích
režimů, které jsou postupně tvrdší a tvrdší (hůře proniknutelné):
Pozor také na vlastnost WPS (Wireless Protection System). Toto je klikací snadnošifrovátko pro líné nebo neznalé uživatele, dostupné na levných SoHo AP. Tato vlastnost představuje díru do Vaší sítě. Je-li Vám bezpečnost Vašeho provozu milá, vypněte WPS a nakonfigurujte WPA2 hezky ručně.
Chcete-li se něco dozvědět o možných útocích na zabezpečení WiFi sítě
včetně WPA2, jako rozcestník můžete použít tyto dva články v češtině:
K čemu? Inu aby se tam nikdo nezvaný nedostal.
Jsou dvě věci k zaheslování:
Hesla používejte pokud možno "silná", odolná proti slovníkovým útokům.
Wifi bridge (nebo "router" nakonfigurovaný jako bridge) bude mít typicky
alespoň jednu IP adresu pro vzdálený management sebe sama.
WiFi router (v routujícím režimu) bude mít na každém rozhraní jinou adresu,
a subnety na jednotlivých rozhraních se nesmí překrývat. Prostě klasický
IP routing a adresace.
V jistém historickém období bylo možno koupit levnější WiFi APčka,
která uměla pouze bridgovat, nebo dražší WiFi routery, které uměly
IP routing a NAT a mívaly bohatší sadu softwarových schopností. Tato doba
je zřejmě nenávratně pryč - dnes nelze koupit nic než router, přičemž
ty opravdu levné routery obvykle nelze nakonfigurovat jako čistý bridge.
U zařízení s pokročilejší konfigurovatelností a větším počtem rozhraní jsou možné i složitější / hybridní konfigurace - porty mohou být rozděleny do několika subnetů (VLAN), a v rámci subnetu/VLAN bude fungovat bridging.
Např. klasická tovární konfigurace malých domácích wifi routerů je:
Wifi + metalické LAN porty v bridgi, WAN port routovaný a navíc NATovaný.
Pokud od takového routeru potřebujeme v zásadě jenom bridge mezi WiFi a LAN,
lze použít jednoduchou fintu: WAN port ponecháme nepoužitý a využijeme pouze
LAN port(y) a WiFi. (Nezapomeňte na takovém routeru vypnout DHCP service
do LAN segmentu, pokud už máte nějaký "svůj" stávající DHCP server,
jinak se budou prát - znáte to o dvou kohoutech na jednom smetišti.)
Abyste se na tento "router degradovaný na bridge" dostali na management,
dejte mu na jeho "LAN rozhraní" nějakou IP adresu ze své stávající sítě.
Levné SoHo routery s více LAN porty mívají uvnitř primitivní
VLANový
switch. CPU routeru má interně k dispozici jedinou síťovku, kterou
provozuje jako
VLANový
trunk, a sousední kus křemíku (VLAN switch
matrix) mu zajišťuje rozplet trunku na jednotlivé untagged porty.
Spřažení několika metalických LAN portů je softwarově nakonfigurováno,
ale provoz mezi metalickými porty je už switchován hardwarem matice.
Bridge mezi metalickými LAN porty a WiFi rádiem je softwarový.
I WAN port je obvykle vyvedený samostatnou VLANou.
Jinak řečeno, dnešní levné SoHo routery obsahují vlastně "router on a stick"
- terminologicky by asi nebylo správné nazývat je L3 switchem,
protože jejich jednoduchá switchovací matice neumí akcelerovat
L3 forwarding.
Pokud použijete jako firmware OpenWRT Linux nebo Mikrotik RouterOS,
můžete páchat všelijaké věci - přiřadit "WAN" port do LANky,
nebo si vyrobit oddělenou DMZ, nebo vůbec oddělit jednotlivé
metalické porty jako samostatná IP rozhraní, dokonce mapovat
virtuální ESSIDy z WiFi rádia na jednotlivé VLANy
(ať už rozpletené na jednotlivé untagged porty,
nebo vyvedené trunkem dál do LAN) apod.
Zmíněné "přípony" znamenají různé varianty modulačního a kódovacího schématu, vzniklé postupným vývojem standardu 802.11. Zvenčí viditelné jsou rozdíly v rychlosti a pracovním frekvenčním pásmu.
Řazeno podle historického postupného vývoje:
Další písmenka označují různé specifické vlastnosti, "kolmé" na modulační
schéma.
Třeba 802.11r znamená standardizovaný rychlý (20 ms) hand-over při roamingu,
s podporou sítě. Týká se aktualizace tabulek MAC adres, předává se rozběhnutá
WPA asociace (bez nového handshaku) apod. Nebo 802.11w = management frame
protection = vylepšení bezpečnosti dílčího aspektu WPA2 (enterprise vychytávka).
Bridging se odehrává v "druhé vrstvě" OSI modelu (zde se bavíme převážně o Ethernetu) a obecně je konfiguračně jednodušší než L3 routing - protože ethernetové bridge/switche se automaticky učí MAC adresy a protože MAC adresy jsou přidělovány v blocích výrobcům hardwaru, kteří je pořadově přidělují - takže na uživatele nezbývá prakticky žádná práce se správou adresního plánu apod.
Pokud v rozsáhlejší ethernetové síti začnete pociťovat přetížení relativně úzkých rádiových pojítek broadcastovým provozem, je na čase přemýšlet o využití routingu na třetí vrstvě. Pokud krabičky na obou koncích rádiového spoje nakonfigurujete jako L3 routery, zbavíte se pronikání broadcastového provozu z metalických segmentů. Znamená to trochu konfigurace navíc. Také pro Vás přestane hrát roli, zda jsou klientské konce ve tří- nebo čtyř-adresním režimu (o tom více v další kapitole).
Pokud potřebujete v rozsáhlejší topologii zařídit redundanci, jde to zařídit jak na druhé, tak na třetí vrstvě. Na druhé vrstvě použijete spanning tree (STP / RSTP), na třetí vrstvě lze použít nějaký dynamický routovací protokol: OSPF, RIP, jsou i další, kromě toho je v některých případech výhodné použít BGP v roli interního routovacího protokolu (iBGP).
V klasickém Ethernetu (metalickém nebo optickém) nese L2 rámec dvě MAC adresy:
adresu zdroje a cíle.
Na wifi je to složitější. Rámec nadále nese původní dvě MAC adresy L2
zdroje a cíle, což mohou být počítače někde dál v ethernetu (pokud je
WiFi rádio zapojeno do bridge), nebo se může jednat o vlastní MAC adresu
zúčastněného WiFi rádia (síťovky). Ovšem kromě těchto "zděděných" obecných
ethernetových MAC adres je pro režii WiFi sítě potřeba, aby rámce nesly
také MAC adresu zdrojového a cílového WiFi rádia - tyto dvě adresy
jsou obecně odlišné od adres komunikujících L2 zařízení (pokud oba konce
wifi spoje fungují jako bridge).
Celkem tedy teoreticky potřebujeme, aby WiFi rámec nesl 4 MAC adresy:
Režijní MAC adresy pro "rádiovou vrstvu" samozřejmě zůstanou koncovým zařízením na "drátovém" ethernetu skryty - odesílající rádio je přidá, a cílové rádio je zase odebere.
Jak již výše zmíněno, režim se 4 adresami je v rámci 802.11 wifi poměrně neobvyklý. Je jednou z klíčových vlastností režimu WDS (AP-to-AP, pro bezdrátové páteře na sdíleném kanálu), který je ještě normou alespoň zmíněn - není ovšem do detailu standardizován, takže implementace různých výrobců nejsou navzájem kompatibilní. Kromě toho se 4-adresní režim používá také v proprietárních rozšířeních 802.11 WiFi, kde je provozován mezi AP a klientem.
A jaký je tedy standardní režim adresace na 802.11 Wifi?
Jedná se o režim se třemi adresami. Počítá se s tím, že rádiový
klient je zároveň koncovým zařízením Ethernetu. Proto má ve WiFi
rámci klientský konec standardně pouze jednu společnou MAC adresu.
Komplikace nastanou, pokud je Vám "shůry dáno" APčko ve standardním
3-adresním režimu (protože slouží běžným kancelářským a telefonním
klientům, kteří nic jiného neumí) a zároveň byste rádi připojili další
kus LANky skrz bridgujícího WiFi klienta.
Pokud pomineme možnost kombinovaného provozu AP+WDS (není často
k vidění), je tu jedno poměrně běžné kompromisní řešení:
klient v 3-adresním režimu, fungující jako "pseudo-bridge".
Klientská wifina zde funguje v zásadě jako L2 bridge, s tím že ovšem
na svém rádiovém rozhraní překládá MAC adresy. Je to tedy obdoba
L3+4 NATu (maškarády), ovšem odehrávající se na vrstvě L2.
Ptáte se, jaká je odvrácená strana mince? Problém je v tom, že spoustu druhů komunikačních relací nejde navazovat zvenčí-dovnitř, tzn. směrem z páteře a rádiového segmentu skrz pseudo-bridge ke koncovému zařízení v "klientské" síti. Relace směrem z klientské sítě skrz rádio ven fungují normálně. Pseudo-bridge patrně provozuje connection tracking a podmínkou je, aby komunikace byla navazována od klienta směrem ven. Pokud se někdo pokusí navázat komunikaci "zvenčí dovnitř", pseudobridge neví, kam ji namapovat.
Ještě zpět k rádiovým MAC adresám:
Rádiové MAC adresy (kromě "své vlastní") zůstanou skryty dokonce
pro generickou ethernetovou vrstvu ovladačů a běžné utility
(ARP, sniffery apod.) na běžném počítači, který je v roli koncového
L2 zařízení a zároveň obsahuje WiFi rádio. (Pozn.: lhostejno, zda je
na rádiovém segmentu použit typický 3-adresní režim, nebo exotický
4-adresní.)
Pro přístup ke sniffování WiFi rámců včetně "rádiových" hlaviček
je potřeba speciální API mezi user-space snifferem a kernelovými
ovladači wifi karty.
Ještě drsnější speciální možností je WiFi karta v "monitor" režimu - v tomto režimu
karta pouze naslouchá, nedokáže se asociovat, zato ukáže rámce
i od sousedních "klientů", které by v režimu "station" přímo
v hardwaru odfiltrovala.
Pro čenichání je vhodnější Linux - na rozdíl od Windowsů dovolí
pasivní "monitoring" režim (pokud ho dovolí rádio) a i v režimu
"station" dovolí obvykle čenichat včetně všech detailů
(Windows některé informace či druhy rádiových rámců odfiltrují).
Zkratka WDS znamená Wireless Distribution Service (což jistě mnohé vysvětluje ;-D
Ve skutečnosti se jedná o způsob, jak propojit několik APček do bezdrátové sítě AP-to-AP s obecnou topologií, s plnohodnotným bridgováním na každém AP, ve sdíleném rádiovém kanálu. (!) APčka bridgují nejen z "metaliky na rádio" a zase zpátky, ale také "z rádia na rádio" - vlastně v rámci jediného L2 portu (WiFi rádia). Vedlejším důsledkem je, že se AP může chovat jako čistě rádiový repeater, bez "drátěné" konektivity.
A protože APčka potřebují "z rádia na rádio" bridgovat i provoz, který o kus dál začíná a končí mimo rádiový segment na nějaké vzdálené metalické síti, a protože NE všechna APčka ve WDS meshi se nutně navzájem vidí (vlastně stejný problém), je třeba si vést pro rádiový segment "tabulku naučených MAC adres".
S tím je ta koncepční potíž, že na rádiu není konkrétní "směr někam dál" vyjádřitelný jako konkrétní fyzický port, ale "směrem někam dál" je protější rádiová stanice - v případě WDS protější APčko (identifikované svou "rádiovou" MAC adresou).
Proto se v režimu WDS používají "asociace" mezi APčky.
APčko ve WDS režimu bridguje provoz navzájem mezi asociacemi
na své rádiové sousedy (a samozřejmě také do "drátěné"
konektivity, pokud nějakou má, a pokud tato případně
není routovaná).
V základní variantě jsou WDS asociace konfigurovány manuálně
- daná asociace se konfiguruje křížem proti sobě na obou
koncích (zúčastněných APčkách).
Existuje také varianta, kdy se asociace navazují dynamicky.
Spolehlivý provoz této varianty vyžaduje, aby se APčka viděla
buď dobře, nebo vůbec, resp. automatické navázání by mělo proběhnout
až od nějakého relativně vysokého prahu SNR, nejlíp ještě s hysterzí
mezi nahozením/shozením asociace (aby nedocházelo k oscilačnímu
ději známému např. jako "flapování").
Pokud jsou asociace konfigurovány manuálně, a administrátor
si dá záležet, aby síť neobsahovala smyčky, lze se ve WDS
režimu obejít bez STP (Spanning Tree Protocol). Není ale
od věci, mít ho zapnutý - ostatně není od věci, mít v rámci
WDS sítě nakonfigurovány redundantní "trasy" (topologie
asociací bude obsahovat smyčky), protože taková síť bude
odolnější vůči výpadkům asociací a APček.
Pokud necháme navazování WDS asociací na automatice,
a máme ve WDS síti víc než 2 APčka, je STP zhola nezbytné.
Některé zdroje (nepříliš autoritativní) tvrdí, že WDS vůbec žádné asociace nepoužívá, že prostě forwarduje (broadcastuje) přijatý paket všem sousedům. Toto možná platilo u některých ultra-primitivních dávných implementací (Orinoco), moderní implementace naopak pro WDS vyžadují STP (např. v kombinaci s WPA). Celkový obrázek je asi takový, že WDS není cosi jednotného a standardního, naopak se různé implementace co do schopností a vnitřností dost podstatně liší.
Jednou praktickou nectností tradiční implementace WDS je to,
že nejde zkombinovat se silnějším šifrováním (WPA/WPA2).
Má to patrně co do činění s 3-adresním režimem, pro který
bylo šifrovací schéma WPA vyvinuto (WDS jede ve 4-adresním módu,
kvůli volnému bridgování a protože AP-to-AP) nebo snad se vztahem
"AP-to-client", který zde není splněn. Tradičně lze ve WDS režimu
použít přinejlepším WEP.
Existují proprietární implementace, které umí WDS kombinované s WPA.
WPA/WPA2 je také obvykle k dispozici u proprietárních implementací,
které provozují 4-adresní režim v kombinaci s rozlišením AP/client
(plnohodnotný bridging na WiFi klientovi) - jsou k vidění
dvě podvarianty tohoto schématu: jedna striktně point-to-point
(AP vezme jediného klienta), druhá point-to-multipoint (AP vezme
víc bridgujících klientů zároveň). Při rozlišení AP/client už
nelze hovořit o tradičním WDS režimu - ale pokud se oprostíme
od ideologického hledání hnid, tak v mnoha konkrétních situacích
tudy vede cesta.
Proč vlastně tolik zdůrazňuji u WDS manuální asociace a bridging
mezi nimi? Ono je to v klasickém 3-adresním režimu AP/client výrazně jinak?
Ano, je to jinak. V klasickém 3-adresním režimu vidí APčko všechny
své klienty přímo, má je jako na dlani, navíc každý klient má jedinou
MAC adresu (pro Wifi i pro generickou ethernetovou L2 vrstvu).
Takže APčko má víceméně seznam MAC adres asociovaných klientů,
tyto má v bridgujícím režimu naučené na svém "wifi" portu.
Pokud přijde z metaliky nebo od klienta nějaký paket, který podle
cílové MAC adresy patří konkrétnímu WiFi klientovi, tak ho APčko
prostě odvysílá rádiem a o víc se nestará (úplně přesně řečeno:
ještě si počká na WiFi ACK, případně řeší retransmisi). Ale nějaký
složitý bridging mezi klienty v rámci rádia se na APčku v zásadě
nekoná.
Z principu fungování WDS (provoz jde přes dva a více hopů
ve sdíleném frekvenčním kanálu) plyne kapacitní neefektivnost WDS.
Pokud použijete WDS na point-to-point spoj (jediný hop) víceméně
kvůli 4-adresnímu režimu, není situace co do využití kapacity kanálu
nijak odlišná od klasického režimu AP/client. Pokud ale bude docházet
k bridgování "z rádia na totéž rádio", pak platí, že efektivní užitečná
kapacita spadne s každým dalším hopem na půlku.
První AP dostane paket odněkud z metaliky a forwardne ho na rádio.
Druhé AP dostane paket, pošle ACK prvnímu AP, pošle užitečný paket
třetímu rádiu. Třetí rádio přijme paket, pošle ACK druhému AP,
a pošle paket dál (např. čtvrtému AP). To znameáná, že pro doručení
paketu napříč WDS sítí je paket vysílán opakovaně, tj. opakovaně
alokuje vysílací čas sdíleného rádiového kanálu (i v případě
bezchybného doručení).
Když se nad tím zamyslíte, teoreticky by z toho vycházel vzorec C(ef) = C / N,
kde C je kapacita a N je počet hopů. Mnozí autoři ale tvrdí,
že kapacita ve skutečnosti spadne s každým dalším hopem na půlku,
tj. C(ef) = C / 2^(N-1). Takže při třech hopech není kapacita třetinová,
ale čtvrtinová (atd.). Moje praktické experimenty se zdají toto potvrzovat...
Dalo by se spekulovat, jak by to asi dopadlo, pokud by se APčka po více
hopech už navzájem neviděla (viděli by se jenom přímí sousedi,
přinejhorším "ob jednoho") - ale to je pustá spekulace, navíc takto
postavená síť (bez plné viditelnosti) by už od pohledu nebyla zrovna
bytelná co do vzájemného rušení mezi APčky a klienty.
Dovolím si shrnout, že WDS je obecně fuj a je třeba se tomu pokud možno vyhnout. Pro point-to-point a point-to-multipoint bridging přes Wifi existují kvalitní proprietární implementace 4-adresního režimu stylem AP/client. A v rozsáhlejších sítích není vůbec špatný nápad, přes WiFi spíše routovat než bridgovat.
V momentě, kdy zprovozňujete nové APčko, je slušnost proskenovat pásmo a najít prázdný kanál. Otázkou je, jakým způsobem na svém stanovišti skenování pásma provedete. Pokud dáte prostě "nalézt APčka" (rádio nastavíte do režimu "station"), najdete skutečně pouze APčka.
Nenajdete případnou blízkou stanici, která má pro Vás třeba i docela silný signál, ale běží v režimu "client" (station). Tu Vám Vaše vlastní stanice nenahlásí - protože při skenování hledá APčka (chytá Beacony). Vidíte v lepším případě někde v dáli relevantní APčko (na které je rušící stanice asociovaná) - a pochopitelně vzdálené APčko může mít z Vašeho pohledu velice slabý signál.
Pokud v takové situaci usoudíte, že je daný kanál relativně čistý (silnou stanici v sousedství nevidíte) a zprovozníte své APčko, dost možná budete bojovat se záhadným rušením z "neviditelného" zdroje. Přesněji řečeno, nemusíte ani pozorovat ztrátovost paketů, ale nízká bude průchodnost - jak Vaše stanice neustále "dává přednost" v rádiovém kanálu navenek "neviditelnému" sousedovi. Kolizím je zabráněno v souladu s WiFi protokolem, ale průchodnost samozřejmě trpí.
Problém nemá snadné řešení. Jedna možnost je zprovoznit v Linuxu pasivní čenichání na WiFi rádiu v "monitoring" režimu (nikoli "station") - nástroje jako Wireshark nebo Kismet pak ukážou, že na kanálu není ticho. Kismet by snad mohl ukázat i sílu signálu "skryté" blízké stanice. Wireshark ukazuje jenom obsah přijatých rámců.
Optimálním nástrojem pro hledání "skrytých uzlů" je obecný přehledový
spektrální analyzátor pro dané pásmo (v kombinaci se směrovou anténou).
Tato hračka je ale pro běžného uživatele / správce / budovatele WiFi
sítí mimo finanční možnosti.
Jako kompromisní řešení existují speciální USB WiFi dongly s upraveným
firmwarem, které skutečně skenují a zobrazují surové rádiové pásmo
- stojí nějaké peníze, ale je to o 1-2 řády míň, než spektrální
analyzátor do 3 nebo 6 GHz.
Problém "skrytého uzlu" může mít ještě jednu polohu / význam / aspekt:
vzájemný problém patrně mohou mít i "spřátelené" stanice na společném AP !
Jak to?
Wifi se snaží řešit kolize v rádiovém kanálu mechanismem CSMA-CA.
Chová se to dost podobně, jako CSMA-CD na klasickém kolizním metalickém ethernetu.
Stanice poslouchá, a pokud slyší ve vzduchu cizí provoz (alespoň preambuli),
nezačne vysílat svůj vlastní paket. Čeká, až cvrkot v éteru utichne.
Výše jsme popisovali problém, kdy v éteru cvrká nějaký soused
na jiném ESSIDu. Zde je problém opačný: může se stát, že neslyšíme
kamarádskou stanici na svém vlastním ESSIDu, přestože ona se s APčkem
vidí a Vy taky. Takže Vy začnete vysílat, protože Vaše stanice má
pocit, že je v éteru dostatečně ticho - ale je to omyl, Vaše stanice
jenom neslyší, že "kamarád" se kterým se přímo nevidíte, mezitím
už taky vysílá. Výsledkem je neošetřená kolize, APčko vidí
chybně přijatý rámec (rozsypané CRC), sníží rychlost, tím si
nepomůže, tak sníží ještě...
Jak to může nastat? Jednoduše: na outdoorových AP se běžně používají
omni nebo sektorové antény. Tzn. AP vidí široko daleko. Ale na klientech
se používají antény, které svítí ostře směrově *pouze* na své AP.
Takže se klidně může stát, že většina klientů utopených v okolní
zástavbě se navzájem v éteru nevidí!
Špičkové WiFi síťovky mají možnost nastavit práh úrovně přijímaného signálu pro detekci kolize. Pod Windows tuto možnost obvykle nenajdete, ale třeba routerboardy od Mikrotiku to tuším umí. Pokud se chcete zbavit "ohleduplnosti vůči sousedům na jiném ESSIDu", je tu možnost zvýšit práh pro detekci kolize. Někteří autoři tvrdí, že toto opatření při vhodném nastavení zvýší celkovou propustnost sousedních WiFi sítí s přeslechem na společném kanálu. Ale pozor: účinek na "problém s kamarády kteří se navzájem nevidí" je přesně opačný :-) Zvednutím prahu pro detekci kolize se problém jedině zhorší...
Popsaný problém jenom dokládá, že technologie WiFi nebyla vyvinuta pro vykrývání koncových uživatelů v outdoorovém prostředí se směrovými anténami na klientu a omni/sektor anténou na AP. Mechanismus CSMA-CA funguje optimálně v prostředí, kde se i koncové stanice dobře vidí navzájem = někde uvnitř budovy, se standardními omni anténkami. Relativně dobře to funguje na point-to-point spojích, kde jsou jenom dva účastníci a baví se přes ostře směrové antény.
Oba problémy, tzn. "jak ignorovat podprahové cizí sousedy"
a "jak se nepřekřikovat s kamarády na společné P2MP síti,
kteří se mezi sebou přímo nevidí", řeší náhrada mechanismu
CSMA-CA mechanismem TDMA, kde APčko přiděluje vysílací čas.
Kamarádi si neskáčou do řeči, protože mají každý svůj
(dynamický a férový) příděl, podprahový cizinec ničemu
nevadí, a případný nadprahový rušič způsobí zcela odůvodněnou
ztrátu paketu... což ale není problém mechanismu TDMA,
je to problém plánování spektra.
TDMA není standardní součástí rodiny WiFi standardů 802.11,
ale existují proprietární implementace, které v tomto režimu vysílají.
Windows XP a vyšší (v tuto chvíli poslední jsou 8.1) obsahují od přírody poměrně slušného WiFi klienta s podporou WPA2 a snad i 802.11r. Umí tedy fungovat v režimu "station". Podporovaná modulační schémata jsou věcí hardwaru a jeho ovladačů.
Windows XP neuměly fungovat jako WiFi AP. Uměly nanejvýš ad-hoc režim. Windows 7 a vyšší umí fungovat jako primitivní AccessPoint. Nebyl by to Microsoft, aby to nezašmodrchal, ale v principu ta možnost existuje. K této funkci se podrobněji vrátíme níže.
Windows neumožňují přístup dostatečně blízko k hardwaru na to, aby
umožnily úplně detailní sniffování provozu na rádiovém kanálu (neumí
režim "monitor").
Prostě NDIS stack a WinAPI neobsahují systémové API, kterým by
tyto podrobnosti šly zjistit.
Nástroje jako Wireshark nebo Inssider si umí některé věci "domyslet",
ale to už je trochu rozdíl oproti skutečnému odposlechu v éteru.
Historicky (XP) bylo možno narazit na slabiny standardního Wifi klienta (MS Wireless Zero Config) například v situaci, kdy ve vzduchu svítil velký počet accesspointů (řádově desítky) - pak přetékal "seznam bezdrátových sítí" a nešlo v něm rolovat. V novějších verzích Windows je tento problém snad odstraněn.
Další drobná muška se objevovala po několika cyklech usnout/probudit, kdy se zasekl jakýsi interní stav "připojeno/odpojeno", ovšem na relativně vysoké vrstvě směrem k uživatelskému rozhraní - ve skutečnosti WiFi spojení fungovalo, DHCP dostalo adresu, data běhala tam i zpátky, ale ikonka v systrayi i záznam v seznamu sítí indikovaly "odpojeno"... (evidentně rozpad synchronizace dvou stavových mechanismů na dvou různých vrstvách).
Různí výrobci WiFi síťovek dodávali spolu se svými ovladači všelijaké
alternativní konfigurační utilitky (obvykle se zabudovaným "supplicantem"
tzn. asociačním a autentikačním klientem). Utilita od výrobce většinou
poskytovala nějaké údaje navíc, např. o aktuálním rádiovém kanálu
a síle signálu v deciBelech. Uměla to třeba utilita od Intelu, ovšem
vybaveností zejména zářila utilita od Atherosu (Atheros Configuration
Utility, ACU). Bohužel Atheros zrušil ACU při přechodu z ovladačů v9
na v10 (což cca korelovalo s akvizicí ze strany Qualcommu) a v rámci v9
byla ACU taky k dispozici pouze pro XP, pro novější Windowsy nikoli.
Navíc byla ke konci nepříjemně chybovatá...
Viděl jsem ještě jednu či dvě konfigurační utility od jiných výrobců,
které byly na úrovni defaultní MS ZCR nebo i horší.
Závěrem kapitoly se ještě stručně vraťme ke zmíněnému "accesspoint" režimu.
V terminologii Microsoftu se tato funkce jmenuje "hosted network"
a je dostupná pouze skrz příkazový řádek. Ovládá se pomocí příkazů jako:
netsh wlan start hostednetwork
netsh wlan stop hostednetwork
netsh wlan set ... (ESSID, WPA2 PSK heslo apod.)
netsh wlan show hostednetwork
netsh wlan show settings
Podrobnější informace lze získat buď
přímo u microsoftu
nebo
na nezávislých webech
které popisují konfiguraci poněkud přístupnější formou.
Hodit se může také videonávod na YouTube, který ukazuje,
jak v device manageru "odkrýt" Microsoft Virtual WiFi Miniport Adapter
(by default je skrytý) a jak ho povolit, pokud je disabled.
Funkce "hosted network" je Microsoftem oficiálně prezentována jako součást "sdílení připojení do internetu" - jako že máte na PC nějaký uplink (dnes patrně metalický Ethernet), a umožníte WiFi klientům, aby se "svezli" s konektivitou do tohoto uplinku. Microsoft moc nerozvádí, zda jsou "podřízení" wifi klienti skryti pomocí NATu, nebo nějaké L2 maškarády (přímo bridgováni patrně nejsou). Čili je to z podobného soudku, jako nedopečený skoro-transparentní soft-bridge podporovaný na metalických síťovkách. Jedno další "špecifikum" je, že po rebootu virtuální APčko nenastartuje automaticky - konfigurační parametry jsou snad dokonce perzistentní, ale nikoli stav "zapnuto". Tzn. pokud chcete "stále zapnuté" AP, musíte ho startovat skriptem po spuštění.
Funkci "hosted network" implementuje stádečko driverů:
shora viditelný vwifimp.sys (Microsoft Virtual WiFi Miniport Adapter Driver),
podporovaný vwififlt.sys (filter driver ve stacku nad HW-specifickým driverem
pro fyzickou wifi síťovku) a vwifibus.sys (patrně nějaká virtuální sběrnice,
na které žijí virtuální wifi adaptéry / ESSIDy). Bude k nim nějaký doprovodný
INF.
Zdá se, že "Microsoft Virtual WiFi" je standardní součástí moderních verzí
Windows, ale pokud ne, existuje stand-alone download,
který by tuto podporu měl přidat. Možná je ještě potřeba kliknout
na "sdílení" ve vlastnostech nějaké jiné síťovky? Těžko říct.
Že to funguje, poznáte podle toho, že v systému existuje
"Microsoft Virtual WiFi" síťovka.
Tento subsystém "Microsoft Virtual WiFi" vyžaduje určitou podmnožinu
NDIS API od low-level driveru pro wifi síťovku - ale počínaje Windows 7
je podpora těchto věcí nutnou podmínkou udělení WHQL certifikace
driveru wifi síťovky, takže reálně je podpora Virtual WiFi ze strany
výrobců wifi čipů v jejich driverech v podstatě automatická.
Konkrétně Intel a Atheros toto umí.
U dual-bandových síťovek (2.4/5 GHz) můžete narazit na nepříliš
dokumentovanou nuanci, že někteří výrobci (tuším snad Intel)
nepodporují AP režim v pásmu 5 GHz. Nebo že snad Windows nepodporují
HostedNetwork v režimu 802.11a, ale funguje v režimu 802.11n v pásmu
5 GHz... už si přesně nepamatuji.
V jednom případě, snad na Win7 Embedded, se nám stalo, že systém původně vůbec neobsahoval Virtual WiFi podporu (chyběly drivery). Pouhým zkopírováním tří .sys souborů a doprovodného INFu (včetně operace "nainstalovat") se nic nestalo. Tuším mi nepomohla ani explicitní instalace stand-alone MSI downloadu. Nakonec tuto funkci vyprostila/zpřístupnila jedna věc: namísto wifi karty Atheros (se kterou jsem původně počítal, a se kterou jsem celou dobu testoval) jsem vrazil do počítače wifi kartu od Intelu. Potažmo jsem musel spustit .EXE instalátor intelího driveru (pod Win7 nebyl v systému od přírody). No a intelí EXE instalátor zřejmě něco učesal v registrech (nevím zda přímo nebo skrz Setup API) a Virtual WiFi se zázračně rozjelo. A fungovalo dál i poté, co jsem intelku vyhodil a vrazil jsem zpátky kartu Atheros (kvůli podpoře AP v pásmu 5 GHz).
Driver pro wifi síťovky Atheros má v registrech konfigurovatelnou
položku zvanou "BandSelect" resp. "NetBand". Definuje klikací
výběr režimu (a/b/g/n) a pásma, dostupný ve vlastnostech adaptéru.
Konkrétně u generace ATH9k okolo AR9380 (driver ve verzi 9.x/10.x)
bývá tato položka v INFu a v registrech dost odbyta, přitom reálně
driver umí nastavit velmi podrobně, jaká množina režimů je
podporována. Jedná se o bitovou masku s velkým množstvím kombinací.
Při pokusech s HostedNetwork se mi toto velice hodilo. Porovnáním
více variant driveru Atheros se mi podařilo rozluštit význam/skladbu
jednotlivých variant bitové masky. Vyrobil jsem si .REG soubor,
který lze přímo importovat do registru. Pozor, pokud zvolíte režim,
který Váš čip nebo driver nepodporuje, driver hodí chybu při
natažení. Bohužel tento atribut je Atheros-specific = nefunguje
s drivery jiných značek (např. Intel má pro čipy generace a/b/g/n
svůj vlastní konfigurovatelný atribut, bohužel mnohem méně detailní)
a nefunguje dokonce ani s drivery Atheros pro staré čipy ath5k,
ani s novým driverem 11.x pro "ACčkové" čipsety z rodiny QCA9880
(položka NetBand existuje, ale obsahuje cosi obskurního). Konkrétně
se mi nepodařilo zjistit bitmasku pro AC na 2.4 a 5 GHz.
=> prostě Windowsy. Hosted Network může být dobrá, pokud chcete
nějaké embedded škatulce vdechnout možnost, připojit se např.
notebookem nebo telefonem (WiFi klientem) a něco si s ní popovídat.
Pokud chcete konfigurovatelné APčko, pořiďte si něco od Mikrotiku
nebo Ubiquiti.
Subsystém Virtual WiFi byl původně experimentálním projektem
uvnitř Microsoftu. Cílem bylo, aby se počítač skrz jednu
fyzickou wifi síťovku (rádio) mohl účastnit několika sítí
(ESSIDů) jako AP nebo stanice (na různých ESSIDech
v různé roli). Microsoft údajně tento původní projekt/tým
rozpustil dávno před uvedením funkce "hosted network",
ale zdá se, že původní obecně pojatá infrastruktura
ze subsystému "Virtual WiFi" dodnes jasně vyzařuje.
Konfigurační rozhraní dodávané Microsoftem je poněkud strohé.
Kromě příkazového řádku je k dispozici také
programátorské API,
které mohou využívat nezávislí autoři softwaru - viz např. Connectify
= komerční klikací front-end k funkci Hosted Network.
(potažmo, pokud Vám nefunguje "hosted network" holýma rukama
v netsh, nebude Vám fungovat ani Connectify.)
Pod Windows XP i pod Windows 7 se vyskytuje problém s těmito příznaky:
WiFi funguje, ale po uspání a probuzení počítače se WiFi znovu nerozběhne.
Buď nahlásí trvale "nepřipojeno", nebo se základní vrstva rádia připojí,
ale už nepřijde odpověď na DHCP Request (patrně se neobnovila
šifrující vrstva WPA2) = po pár vteřinách se na ikonce připojeného
rádia objeví vykřičník ve žlutém trojúhelníku.
V některých případech stačí zhasnout a znovu rozsvítit rádio na klientu
- starší notebooky na to mívaly tlačítko nebo klávesovou zkratku. Ale novější
notebooky už tlačítko na vypnutí WiFi nemívají, nebo to na rozcvičení wifiny
nezabere - a je potřeba restartnout AP nebo celý počítač...
Jedná se už na první pohled (na různých postižených strojích) o mírně
odlišné příznaky, a odpovědi v odborných fórech potvrzují, že se nejedná
o jeden konkrétní známý problém, ale o celou třídu různých možných zádrhelů,
nekompatibilit apod. V zásadě málokdy je problém na straně AP, problém je
třeba hledat nejspíš někde ve Windowsech. Wifinový stack a generický
síťový stack má mnoho vrstev, interní API pro ovladače WiFi hardwaru
je o něco složitější než API pro generické ethernetové ovladače,
zveřejněné API pro WiFi ovladače a reálné interní chování kernelu
v této oblasti na straně Microsoftu se v průběhu let mírně vyvíjelo,
rozdíly přicházely nejen s novými service packy, ale občas i s
Windows Update, odhadem i následkem bezpečnostních záplat apod.
Do síťového stacku (ne nutně do WiFi) háčkují své filtry například
také antivirové softwary třetích stran i Microsoftu...
Nakonec je tedy každý počítač do značné míry unikátem - každý má
jiný antivirový software, potenciálně trochu jinou sadu Windows updatů,
jinou historii změn ve Windows Registry, jiný wifi hardware
a k němu jinak starou verzi ovladače... (nedejbože jinou historii
zaháčkovaného a odstraněného malwaru)
Pokud tedy máte problémy s rozběhem WiFi po probuzení počítače ze spánku, lze doporučit snad jen stažení všech Windows Updatů a aktualizaci ovladače WiFi hardwaru na poslední verzi od výrobce. S trochou štěstí to pomůže.