Wifi sildamine

Miks on client mode's WiFi bridge juba oma olemuselt äärmiselt jabur asi ja miks on WRT54G kasutamine sellises kontekstis Halb Mõte ;(

Häda on lühidalt järgmine: WiFi võrk on peaaegu nagu ethernet koaksiaalkaablis, st. paketid, mis võrgus liiguvad, on üsna tavalised etherneti paketid pluss veel pisut 802.11 spetsiifilist juttu... Esialgu tunduks, et kõik on väga hea - kui on ethernet, siis saab ju seda ka bridgeda, eks? Wrong!

Kahjuks, erinevalt tavalisest koaksiaal ethernetist, kus ühtegi liiklust vahendavat seadet ei ole (või kui on, siis on need etherneti seisukohalt läbipaistvad, ntx. hub või repeater), käib WiFi puhul kogu liiklus AP'st läbi. AP aga peab nimekirja klientidest, kes on antud võrgu külge assotseerunud, seetõttu on AP jaoks äärmiselt oluline, milliselt MAC aadressilt üks või teine pakett tuleb... ning ongi sedasi, et paketti, mille source MAC aadress ei kuulu ühelegi assotseerunud kliendile, lihtsalt ignoreeritakse.

Ent see on täpselt see olukord, mis tekkib, kui me asetame WiFi võrku client modes bridge (kusjuures ei ole vahet, kas see bridge on lahendatud softiliselt nagu WRT54G sees või kuidagi raualiselt). Kuna tavaline bridge paketi enese sees mitte midagi ei muuda, siis saabuvad WiFi võrku ja seetõttu ka AP'le paketid, mille source MAC aadressidest ta mitte midagi ei tea - need MAC'id on ju meie bridge taga kuskil kaabli küljes. Loomulikult ignoreerib AP neid pakette ning kogu ilus idee ei kõlba enam pruunkaru pärasoolde kah mitte...

Et sellest hädast üle saada, ongi välja mõeldud selline jubedus nagu WET, mille puhul client modes bridge saadab tema küljes olevast kaabliga etherneti võrgust tulnud paketid välja oma MAC aadressiga(sellega, mis on AP'le teada kui assotseerunud seadme aadress) ning peab sisemiselt sellise translatsiooni kohta mingit tabelit, kus on ilmselt kirjas, millise MAC aadressi taga on milline IPv4 aadress - kuidagi on ju vaja WiFi võrgule ARP'e valetada (midagi ARP Proxy laadset). WET'i võib vaadata kui MAC aadressi põhist source NAT'i...

On ilmselge, et selline koletu lahendus töötab täpselt nii hästi, kui hästi on seadmes aadresside translatsioon lahendatud... Üldiselt, tavaline unicast IPv4 liiklus isegi töötab, IPv4 Multicast suure tõenäosusega ei tööta (ei ole viitsinud proovida), IPv6 ei tööta (proovitud) ning ilmselt ei tööta ka IPX ega muud mitte IPv4 protokollid. Ühesõnaga võib-olla antud võrgus ajab WET asja ära, kuid garanteerida ma küll midagi ei julgeks.

Tasub märkida veel, et client mode's bridgena ei oska WRT54G töötada võrgus, kus on WEP krüpto - miks ei tööta, ei tea - WiFi'st eetri poole paketid liiguvad, eetrist WiFi poole mitte, samas tcpdumbiga on näha, et softi jaoks kupatatakse pakett interfeissi, kuid õhku midagi ei jõua.

Samuti ei ole WRT54G client mode's kuigi stabiilne (ei bridgena ega ka ilma) - tihedama liiklusega võrgus jookeb nii kord või paar päevas kokku (tõsi, ta teeb sellisel juhul alati restardi (mingi sisemine watchdog?) ning ühendus taastub üsna pea, ent ebameeldiv ikkagi)... Miks ikaldub, ei tea, miks ikaldub aga vat, ikaldub...

Kokkuvõtteks, mitte-bridgena (näiteks ruuterina) on WRT54G client modes enam-vähem kasutatav seade(kui harvad restardist tekkinud paari sekundilised katkestused ei häiri või kui liiklus ei ole eriti tihe), ent nagu alguses öeldud client modes WiFi bridge on juba oma olemuselt jabur...

Tjah, ilmselt on olemas ka seadmed, mis suudavad olla client mode bridged inimlikul viisil - näiteks assotseerides AP vastu iga viimase kui MAC aadressi, mis tahab midagi WiFi võrku rääkida kuid arvatavasti on need seadmed oluliselt kallimiad kui WRT54G. Kuid isegi sellisel juhul ei ole see lahendus kuigi ilus - mis saab siis, kui üle WiFi kokku bridgetavates eetri segmentides on sadu masinaid, mis mingil põhjusel teise segmenti midagi saata tahavad?

Autor: wookie