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é):
K čemu? Inu aby se tam nikdo nezvaný nedostal.
Jsou dvě věci k zaheslování:
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.
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:
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í).
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.
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.
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 od přírody neumí fungovat jako WiFi AP. Umí nanejvýš ad-hoc režim.
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. Prostě NDIS stack a WinAPI neobsahují systémové API, kterým by tyto podrobnosti šly zjistit.
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 od
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 úrovní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ší.
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.
FCC průmyslové systémy je technicko – obchodní společností, zastupující významné výrobce v oblasti průmyslové automatizace a telekomunikační techniky. V oblasti průmyslové automatizace zahrnuje naše nabídka spektrum sahající od senzorových systémů přes průmyslové sběrnice a průmyslové komunikace po průmyslové výpočetní, řídicí a dispečerské systémy na bázi specializovaných PC. Naší významnou specializací jsou systémy pro strojové vidění využívané v oblasti výrobní automatizace a kontroly kvality. Spolupracujeme s nejvýznamnějšími světovými dodavateli průmyslové výpočetní techniky a komunikací z Evropy a Asie a disponujeme i vlastním vývojovým a konstrukčním zázemím včetně vývoje softwaru.
FCC průmyslové systémy s.r.o.
U Výstaviště 138/3, Holešovice
170 00 Praha 7
Email: info@fccps.cz
Tel.: +420 472 774 173
