Základní přehled o technologii WiFi

František Ryšánek [ rysanek AT fccps DOT cz ]

Obsah

Obecné poznámky

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.

Nejdůležitější konfigurovatelné parametry

Rádiový kanál

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.

Nastavení státu (Country)

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).

Jméno sítě - ESSID

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).

Šifrování provozu

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ě:

Hesla - k čemu?

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.

IP adresy

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.

Režimy 802.11a/b/g/n/ac/ad

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).

Pokročilé zádrhele

Routing vs. bridging

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).

3-address vs. 4-address mode

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:


Takto funguje "režim se čtyřmi adresami", který je ovšem na Wifi ve skutečnosti dost atypický.

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í).

Základní poznatky o WDS

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.

Problém skrytého uzlu

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í.

Co vlastně umí (a neumí) s wifinou Windows

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.)

Problém: po probuzení Windowsů nenajede wifi

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.