Jaké používáte ve své bezdrátové síti zabezpečení? Stařičký WEP nebo novější WPA (2), třeba i s PSK? Jakou šifru a délku klíče? Jaký je váš názor, jak by měli být jednotlivé typy sítí šifrovány - domácí, firemní, jiná?
Já doteď používal u domácí sítě WPA2-AES, autentizace PSK, ale vzhledem k tomu, že mi zde jeden dobrý člověk poradil, že čím vyšší zabezpečení, tím může docházet k vyššímu zbrždění přenosu, rozhodl jsem se přejít na obyčejné WPA. WEP nikdy, ten je prolomitelný během chvíle :)
Já doteď používal u domácí sítě WPA2-AES, autentizace PSK, ale vzhledem k tomu, že mi zde jeden dobrý člověk poradil, že čím vyšší zabezpečení, tím může docházet k vyššímu zbrždění přenosu, rozhodl jsem se přejít na obyčejné WPA. WEP nikdy, ten je prolomitelný během chvíle :)
Používám WPA2-PSK a nepřipadá mi, že by to bylo nějak bržděné (ale může být :D). Jinak nyní mám uplně obyčejný WiFi router od Belkinu. Dříve jsem používal Straightcore WRT-312 a tam jsem používal WPA2-PSK + filtraci MAC adres, ten ale nyní slouží jako AP. Jinak doma na to mám připojené 3 PC (2xkabel, 1xNTB WiFi). :thumb A heslo bych měl mít 11místné. :notsure
Vše funguje jak má...ale časem bych rád zakoupil Asus WL-500gP...kvůli USB portům na externí HDD. :inlove
Vše funguje jak má...ale časem bych rád zakoupil Asus WL-500gP...kvůli USB portům na externí HDD. :inlove
Ja pouzivam WPA2-PSK (AES) , i kdyz nevim proc potrebujes po wifi prenaset "velky data" . Wifina je rozsireni netu po byte bez dratu, sam to mam udelano tak ze pokud chci kopirovat GB dat tak si notase polozim na stul a pichnu TPckem do switche. Nechci ti brat iluze, ale vykon te WL500 jako NAS serveru je jedna velka mizerie, kamarad mi rikal ze nekde na netu nasel neco o rychlostech kolem 300-400 KB/sec , coz nestaci ani pousteni DVD . Rozsiritelnost te WL500 je pomerne dobra za tu dobu co je na trhu pro ni vzniklo spoustu custom firmwaru.
Withman: Já teď pomaloučku zase přecházím na RouterBoard RB192 :) a heslo mám dlouhé něco kolem 40 znaků. Ne, neupsal jsem se :D
BTW: Až se tu objeví nějaký mod, nešlo by přidat do ankety ještě jednu možnost "Zabezpečení nepoužívám?" Takových lidí je asi pořád ještě dost :)
// neviem, či to systém vôbec dovoľuje (eraser)
BTW: Až se tu objeví nějaký mod, nešlo by přidat do ankety ještě jednu možnost "Zabezpečení nepoužívám?" Takových lidí je asi pořád ještě dost :)
// neviem, či to systém vôbec dovoľuje (eraser)
Ještě tam chybí možnost "WPA2 a nad tím VPN" kterou používám já (já vím, jsem holt moc paranoidní :D)
Dneska je těch Wi-Fi všude tolik, že na tom, co používám mi stačí klasický WEP. Ono to stejně má tak mizernej dosah, že je to v zásadě skoro jedno, i kdybych to měl nešifrovaný :) Ale pro jistotu, že ;)
WEP 128 + MAC filter + VPN ke gateway
Tim se vykon potrebny na zabezpeceni neodrazi v propustnosti Wifi.
Tim se vykon potrebny na zabezpeceni neodrazi v propustnosti Wifi.
Nojestli je ta VPN šifrovaná, tak to nebude spíš náročnější, než samotný WPA2? Vždyť se tam šifruje dvakrát... Dělal jste někdo testy?
Jestli pakováním myslíš kompresi, pak rozdíl je - ale to se při VPN over WIFI neprovádí. Jestli myslíš pakováním něco jiného, tak by mně zajímalo co... :-) Že by tunelování?
WEP šifruje symetrickou šifrou. (akorát s příliš slabým klíčem, což spolu s částečnou možností předvídat co po síti běží vytváří možnost WEP prolomit asi tak za pět minut sledování provozu).
VPN jako takové nešifruje (pak síť zatěžuje pouze minimálně - přenášením dvojích hlaviček) - tady ale nevím, jakým by byla bezpečnostním přínosem. A pokud se rozjede šifrovaná VPN, tak se šifruje dvakrát, jednou data na vstupu do VPN a jednou zapomocí WEP....
WEP šifruje symetrickou šifrou. (akorát s příliš slabým klíčem, což spolu s částečnou možností předvídat co po síti běží vytváří možnost WEP prolomit asi tak za pět minut sledování provozu).
VPN jako takové nešifruje (pak síť zatěžuje pouze minimálně - přenášením dvojích hlaviček) - tady ale nevím, jakým by byla bezpečnostním přínosem. A pokud se rozjede šifrovaná VPN, tak se šifruje dvakrát, jednou data na vstupu do VPN a jednou zapomocí WEP....
wpa2-psk (aes) + filtovani mac
skryty ssid, i kdyz to zas tak velky vyznam nema - lamky to v prvni fazi nevidi :)
vpn jsem jeste nezkousel, ale mrknu po clancich na netu a popr. vyzkousim
skryty ssid, i kdyz to zas tak velky vyznam nema - lamky to v prvni fazi nevidi :)
vpn jsem jeste nezkousel, ale mrknu po clancich na netu a popr. vyzkousim
[quote=slowak1982;129769]skryty ssid, i kdyz to zas tak velky vyznam nema - lamky to v prvni fazi nevidi :)[/quote]Ono o lamky nejde, avšak pokiaľ neexistuje žiadna aktívna konektivita, tak potom SSID nezistí nikto, takže sieť je skrytá, čiže pokiaľ je niekto na "výjazde" a nenájde nič, tak sa na dané miesto ťažko vráti.
Naviac chcem vidieť takého machra, ktorý by mi dokázal hacknúť WPA2+AES s 504 bitovým kľúčom, s MAC filtrovaním a statickými IP adresami. :eek:
Naviac chcem vidieť takého machra, ktorý by mi dokázal hacknúť WPA2+AES s 504 bitovým kľúčom, s MAC filtrovaním a statickými IP adresami. :eek:
[QUOTE=Logout;129724]Jestli pakováním myslíš kompresi, pak rozdíl je - ale to se při VPN over WIFI neprovádí. Jestli myslíš pakováním něco jiného, tak by mně zajímalo co... :-) Že by tunelování?
WEP šifruje symetrickou šifrou. (akorát s příliš slabým klíčem, což spolu s částečnou možností předvídat co po síti běží vytváří možnost WEP prolomit asi tak za pět minut sledování provozu).
VPN jako takové nešifruje (pak síť zatěžuje pouze minimálně - přenášením dvojích hlaviček) - tady ale nevím, jakým by byla bezpečnostním přínosem. A pokud se rozjede šifrovaná VPN, tak se šifruje dvakrát, jednou data na vstupu do VPN a jednou zapomocí WEP....[/QUOTE]
Ano pakovanim myslim kompresi, je videt ze tusis o cem se mluvi takze nejak nepobiram tu tvoji puvodni IMHO naprosto zbytecnou a stupidni otazku.
VPN pouzivam samozrejme pres sifrovane spojeni SSH, ale ne oddeleny tunel, komplexni VPN.
Eraser: Da se hacknout jakekoli sifrovani, nejslabsim prvkem je totiz vzdy klient, takze kdyz vytvoris FAKE POINT, klient ti vesele posle kompletni inicializaci komunikace, neni to jednoduche, je potreba mit na to vlastni utilitky a nejlepe upraveny firmware ve wi-fi zarizeni, ale da se.
Taky tohle sifrovani extremne omezuje propustnost a zere vykon prvku.
Na univerzite se nekolik lidicek snazi vyvinout selektivni sifrovani, kdy u multimedialnich streamu a podobne narocnych toku ktere neni potreba sifrovat se sifruji pouze havicky dat a zbytek se nezpracovava, ale do prakticke implementace je jeste daleko a buh vi jestli se toho nekdo chytne.
WEP šifruje symetrickou šifrou. (akorát s příliš slabým klíčem, což spolu s částečnou možností předvídat co po síti běží vytváří možnost WEP prolomit asi tak za pět minut sledování provozu).
VPN jako takové nešifruje (pak síť zatěžuje pouze minimálně - přenášením dvojích hlaviček) - tady ale nevím, jakým by byla bezpečnostním přínosem. A pokud se rozjede šifrovaná VPN, tak se šifruje dvakrát, jednou data na vstupu do VPN a jednou zapomocí WEP....[/QUOTE]
Ano pakovanim myslim kompresi, je videt ze tusis o cem se mluvi takze nejak nepobiram tu tvoji puvodni IMHO naprosto zbytecnou a stupidni otazku.
VPN pouzivam samozrejme pres sifrovane spojeni SSH, ale ne oddeleny tunel, komplexni VPN.
Eraser: Da se hacknout jakekoli sifrovani, nejslabsim prvkem je totiz vzdy klient, takze kdyz vytvoris FAKE POINT, klient ti vesele posle kompletni inicializaci komunikace, neni to jednoduche, je potreba mit na to vlastni utilitky a nejlepe upraveny firmware ve wi-fi zarizeni, ale da se.
Taky tohle sifrovani extremne omezuje propustnost a zere vykon prvku.
Na univerzite se nekolik lidicek snazi vyvinout selektivni sifrovani, kdy u multimedialnich streamu a podobne narocnych toku ktere neni potreba sifrovat se sifruji pouze havicky dat a zbytek se nezpracovava, ale do prakticke implementace je jeste daleko a buh vi jestli se toho nekdo chytne.
[quote=|Mio|;130545]Na univerzite se nekolik lidicek snazi vyvinout selektivni sifrovani, kdy u multimedialnich streamu a podobne narocnych toku ktere neni potreba sifrovat se sifruji pouze havicky dat a zbytek se nezpracovava, ale do prakticke implementace je jeste daleko a buh vi jestli se toho nekdo chytne.[/quote]
Tak tohle vypadá velmi zajímavě. Je to jen anonymní projekt, nebo se dá o něm něco dočíst na netu, případně připojit?
Tak tohle vypadá velmi zajímavě. Je to jen anonymní projekt, nebo se dá o něm něco dočíst na netu, případně připojit?
[quote=|Mio|;130545]Da se hacknout jakekoli sifrovani, nejslabsim prvkem je totiz vzdy klient, takze kdyz vytvoris FAKE POINT[/quote]Ale to už zachádzame do iných sfér wifi hackingu a počítačovej kriminality. Ide o fakt, že súčasné zabezpečenie wifi pre domácnosti a menšie firmy je s WPA2+AES na slušnej úrovni a nejaký warwalker, či warchalker nemá šancu na úspech. A pre firmy a iné inštitúcie s dôrazom na bezpečnosť platí, že používajú pokročilé metódy autentifikácie, autorizácie a accountingu, častokrát je šifrovanie wifi kombinované s VPN, používajú sa RADIUS servre, wifi MESH, prípadne je wifi fyzicky oddelené od internej siete.
[quote=|Mio|;130545]Taky tohle sifrovani extremne omezuje propustnost a zere vykon prvku.[/quote]Ak je na to zariadenie prispôsobené, tak je táto režijná náročnosť zanedbateľná. A zase nezaraďujme wifi do kategórie, kam vôbec nepatrí a v ktorej je voči metalickej, či optickej sieti úplným žebráčikom.
[quote=|Mio|;130545]Taky tohle sifrovani extremne omezuje propustnost a zere vykon prvku.[/quote]Ak je na to zariadenie prispôsobené, tak je táto režijná náročnosť zanedbateľná. A zase nezaraďujme wifi do kategórie, kam vôbec nepatrí a v ktorej je voči metalickej, či optickej sieti úplným žebráčikom.
to mio:
Pak jsem jaksi nepochopil, proč se tu bavíš o pakování, když všichni ostatní o šifrování....
Btw. ten Tebou navrženej útok - teda jestli jsem to dobře pochopil - že vytvoříš falešnej server, ke kterýmu se budou klienti autentifikovat tak neni tak jednoduchej. Klient totiž neposílá AP heslo, ale něco heslem zašifrované, a to heslo z toho IMHO neni trviální způsob zjistit (ale netvrdim, že tam neni kryptografická díra, jen o ní nevim, rád se poučim).
Na druhou stranu AP při každé autentizaci vytváří jiný, náhodný klíč spojení (vzniklý jako kombinací PSK
a naáhodného čísla, které sdělí klientovi), takže metody založenýna replikace autentizačních odpovědí taky selžou. Něco o hackování WPA2 je tady (ale je to tři roky starým tak možná jsem něco nezaregistroval a už se to umí...)
http://www.hsc.fr/ressources/articles/hakin9_wifi/index.html.en
Jinak nevím jestli Tě chápu (místo jednovětejch výkřiků a řečech o blbejch otázkách bys to třeba moh víc vysvětlit, proč máš danej názor), ale jsem přesvědčenej, že součet časů na provedení zašifrování pomocí SSH a následně WEP je větší, než jedno zašifrování pomocí WPA2. Navíc WPE dneska jako kdyby nebylo (hacknutý je tuším cca za 10min), takže IMHO je dobrý řešení buďto VPN bez šifrování, nebo VPN + WPA2 pro paranoiky/"rozumný lidi" (dosaďte si slovo podle toho, jestli jste paranoici/důvěřivci nebo rozumný lidi :-D :-D).
Pak jsem jaksi nepochopil, proč se tu bavíš o pakování, když všichni ostatní o šifrování....
Btw. ten Tebou navrženej útok - teda jestli jsem to dobře pochopil - že vytvoříš falešnej server, ke kterýmu se budou klienti autentifikovat tak neni tak jednoduchej. Klient totiž neposílá AP heslo, ale něco heslem zašifrované, a to heslo z toho IMHO neni trviální způsob zjistit (ale netvrdim, že tam neni kryptografická díra, jen o ní nevim, rád se poučim).
Na druhou stranu AP při každé autentizaci vytváří jiný, náhodný klíč spojení (vzniklý jako kombinací PSK
a naáhodného čísla, které sdělí klientovi), takže metody založenýna replikace autentizačních odpovědí taky selžou. Něco o hackování WPA2 je tady (ale je to tři roky starým tak možná jsem něco nezaregistroval a už se to umí...)
http://www.hsc.fr/ressources/articles/hakin9_wifi/index.html.en
Jinak nevím jestli Tě chápu (místo jednovětejch výkřiků a řečech o blbejch otázkách bys to třeba moh víc vysvětlit, proč máš danej názor), ale jsem přesvědčenej, že součet časů na provedení zašifrování pomocí SSH a následně WEP je větší, než jedno zašifrování pomocí WPA2. Navíc WPE dneska jako kdyby nebylo (hacknutý je tuším cca za 10min), takže IMHO je dobrý řešení buďto VPN bez šifrování, nebo VPN + WPA2 pro paranoiky/"rozumný lidi" (dosaďte si slovo podle toho, jestli jste paranoici/důvěřivci nebo rozumný lidi :-D :-D).
[QUOTE=eraser;129885]Ono o lamky nejde, avšak pokiaľ neexistuje žiadna aktívna konektivita, tak potom SSID nezistí nikto, takže sieť je skrytá, čiže pokiaľ je niekto na "výjazde" a nenájde nič, tak sa na dané miesto ťažko vráti.
Naviac chcem vidieť takého machra, ktorý by mi dokázal hacknúť WPA2+AES s 504 bitovým kľúčom, s MAC filtrovaním a statickými IP adresami. :eek:[/QUOTE]
No já to beru jako možnost udělat potencionálnímu útočníkovi překážku navíc. A taky nejde jen o lidi na výjezdě, ale mužou to zkoušet sousedi nebo děti sousedů apod. Pomalu každý teenager/"hacker" je script kiddie :)
Naviac chcem vidieť takého machra, ktorý by mi dokázal hacknúť WPA2+AES s 504 bitovým kľúčom, s MAC filtrovaním a statickými IP adresami. :eek:[/QUOTE]
No já to beru jako možnost udělat potencionálnímu útočníkovi překážku navíc. A taky nejde jen o lidi na výjezdě, ale mužou to zkoušet sousedi nebo děti sousedů apod. Pomalu každý teenager/"hacker" je script kiddie :)
[quote=Logout;130615]Navíc WPE dneska jako kdyby nebylo (hacknutý je tuším cca za 10min)[/quote]
Pre upresnenie by som dodal, že ono to záleží od prevádzky, tzn. čím lieta vzduchom viacej framov, tým lepšie pre hackera. Je známe, že WEP šifra je slabá, chybná, no v dobách, keď iné nič nebolo a na nových štandardoch sa pracovalo, tak napr. Cisco používalo svoju vlastnú proprietárnu techniku, ktora je obdobou TKIP - časovej zmeny kľúčov.
Inak tu nedávno padlo, že šifrovanie sa dá zlomiť, čo je pravda, avšak i keď niekto nájde tzv. reverzný vzorec, súčasné výkony bežných počítačov by sa trápili kľudne i niekoľko desaťročí a pokiaľ sa aplikuje viacbitové šifrovanie, čas prielomu sa logaritmicky zväčšuje. Takže pokiaľ nemá šifra slabé miesto, ako to bolo u WEP, tak nikto nie je schopný niečo dešifrovať bez správneho hesla. A ako som naznačil, aj keby sme zázrakom získali zo dňa na deň výkonnejší procesor, stačí pridať viac bitov a sme opäť tam, kde dnes.
Pre upresnenie by som dodal, že ono to záleží od prevádzky, tzn. čím lieta vzduchom viacej framov, tým lepšie pre hackera. Je známe, že WEP šifra je slabá, chybná, no v dobách, keď iné nič nebolo a na nových štandardoch sa pracovalo, tak napr. Cisco používalo svoju vlastnú proprietárnu techniku, ktora je obdobou TKIP - časovej zmeny kľúčov.
Inak tu nedávno padlo, že šifrovanie sa dá zlomiť, čo je pravda, avšak i keď niekto nájde tzv. reverzný vzorec, súčasné výkony bežných počítačov by sa trápili kľudne i niekoľko desaťročí a pokiaľ sa aplikuje viacbitové šifrovanie, čas prielomu sa logaritmicky zväčšuje. Takže pokiaľ nemá šifra slabé miesto, ako to bolo u WEP, tak nikto nie je schopný niečo dešifrovať bez správneho hesla. A ako som naznačil, aj keby sme zázrakom získali zo dňa na deň výkonnejší procesor, stačí pridať viac bitov a sme opäť tam, kde dnes.
to eraser: exponenciálně, ne logaritmicky, to by to tak hrozný nebylo :-) - aspoň teda u šifer stojících na problému faktorizace složeného čísla na prvočísla.
slowak1982: problém je v tom, že všude po internetu běhaj návody a utilitky na cracknutí WEP. Takže už to moc nefunguje ani jako obrana proti script kiddies.
slowak1982: problém je v tom, že všude po internetu běhaj návody a utilitky na cracknutí WEP. Takže už to moc nefunguje ani jako obrana proti script kiddies.
Odtud je to OT:
[quote=Logout;130615]....[/quote]
Zkratim to, neber to jako urazku,ale si "tupej".
o kompresi (pakovani) jsem se zminil jako reakce na toto "Nojestli je ta VPN šifrovaná, tak to nebude spíš náročnější, než samotný WPA2? Vždyť se tam šifruje dvakrát... Dělal jste někdo testy?"
Protoze to plati u komprese, neboli komprese jiz zkomprimovaneho je narocnejsi, narozdil od sifrovani, sifrovani jiz zasifrovaneho je stejne narocne na vykon jako sifrovani nezasifrovaneho. To ze se sifruje 2x prave rozlozim mezi router a PC, takze ten vykon navic se "strati" ve vykonu PC.
A co se tyce prolamovani WPA tak sem o zadnym serveru nemluvil, nauc se lepe cist a zamyslet se nad tim.
A konec, uz to nepitvam a prosim radsi me ignoruj, kazi mi to naladu. Ja tebe budu ignorovat od ted.
ODTUD UZ TO NENI OT:
eraser:
K upresneni proc secure VPN skrz WEP sifrovanou sit, protoze vetsina Wi-Fi g prvku (neprofesionalnich, u profi to resi HW navic) ma propustnost maximalne 2 MB/sec klient 2 klient, v prumeru spise k 1MB/sec.
(kde jsou ty teoreticke hodnoty 6MB/sec)
Kdyz nasadim WPA2, vyleze mi ping o 20-80 ms v zavislosti na zatezi (Testovano na cca 8 nejprodavanejsich routerech) a propustost mezi bezdratovymi klienty se jeste snizi. Pozor, jde mi hlavne o komunikaci vice bezdratovych klientu mezi sebou.
Kdyz necham WEP 128 udrzim rozumnou propustnost i ping a vykon potrebny na zabezpeceni se presune na PC/SERVER kde se to samozrejme vubec neprojevi na vykonu.
Vysledkem, je, ze kdyz uz se nekdo naboura do site skrz WEP, naprosto nebude vedet co dal, jedina komunikace kterou tam muze dale odposlechnout je dostatecne sifrovana na to, aby trvalo par let nez by prolomil klice a je odolna proti Men i the middle ataku.
Viditelna budou jen 2 IP adresy s jedinym otevrenym portem.
Nemluve o tom ze se da takhle nachystat krasna past, nechat utocnika prolomit WEP a pak se prozradit jakoukoli neocekavanou komunikaci.
Co se tyka prolomeni WPA2 je to skutecne jen veci profiku, kteri to delaji za prachy, je to narocne na vykon a hlavne na HW, protoze vytvorit dve zrcadla a most mezi nimi a pak pretrhnout most a donutit klienta aby odpovidal na tve klice a pak sehnat vykon odpovidajici kvalite hesla aby ho dokazal desifrovat je spousta nakladu a casu.
Takze abych to shrnul, podle me je nejlepsi vicevrstve zabezpeceni prave s HW oddelenim jednotlivych vrstev komunikace. Ja jsem zvolil tuto kombinaci, samozrejme je mozne pouzit treba prave WPA2 s AES, ale tam prave chybi to HW odeleni jednotlivych vrstev a o veskerou autorizaci a sifrovani se stara jeden prvek, ktery ma omezeny vykon, rekneme si narovinu kolik poskytovatelu treba internetu pres Wi-Fi pouziva profesionalni prvky.
[quote=Logout;130615]....[/quote]
Zkratim to, neber to jako urazku,ale si "tupej".
o kompresi (pakovani) jsem se zminil jako reakce na toto "Nojestli je ta VPN šifrovaná, tak to nebude spíš náročnější, než samotný WPA2? Vždyť se tam šifruje dvakrát... Dělal jste někdo testy?"
Protoze to plati u komprese, neboli komprese jiz zkomprimovaneho je narocnejsi, narozdil od sifrovani, sifrovani jiz zasifrovaneho je stejne narocne na vykon jako sifrovani nezasifrovaneho. To ze se sifruje 2x prave rozlozim mezi router a PC, takze ten vykon navic se "strati" ve vykonu PC.
A co se tyce prolamovani WPA tak sem o zadnym serveru nemluvil, nauc se lepe cist a zamyslet se nad tim.
A konec, uz to nepitvam a prosim radsi me ignoruj, kazi mi to naladu. Ja tebe budu ignorovat od ted.
ODTUD UZ TO NENI OT:
eraser:
K upresneni proc secure VPN skrz WEP sifrovanou sit, protoze vetsina Wi-Fi g prvku (neprofesionalnich, u profi to resi HW navic) ma propustnost maximalne 2 MB/sec klient 2 klient, v prumeru spise k 1MB/sec.
(kde jsou ty teoreticke hodnoty 6MB/sec)
Kdyz nasadim WPA2, vyleze mi ping o 20-80 ms v zavislosti na zatezi (Testovano na cca 8 nejprodavanejsich routerech) a propustost mezi bezdratovymi klienty se jeste snizi. Pozor, jde mi hlavne o komunikaci vice bezdratovych klientu mezi sebou.
Kdyz necham WEP 128 udrzim rozumnou propustnost i ping a vykon potrebny na zabezpeceni se presune na PC/SERVER kde se to samozrejme vubec neprojevi na vykonu.
Vysledkem, je, ze kdyz uz se nekdo naboura do site skrz WEP, naprosto nebude vedet co dal, jedina komunikace kterou tam muze dale odposlechnout je dostatecne sifrovana na to, aby trvalo par let nez by prolomil klice a je odolna proti Men i the middle ataku.
Viditelna budou jen 2 IP adresy s jedinym otevrenym portem.
Nemluve o tom ze se da takhle nachystat krasna past, nechat utocnika prolomit WEP a pak se prozradit jakoukoli neocekavanou komunikaci.
Co se tyka prolomeni WPA2 je to skutecne jen veci profiku, kteri to delaji za prachy, je to narocne na vykon a hlavne na HW, protoze vytvorit dve zrcadla a most mezi nimi a pak pretrhnout most a donutit klienta aby odpovidal na tve klice a pak sehnat vykon odpovidajici kvalite hesla aby ho dokazal desifrovat je spousta nakladu a casu.
Takze abych to shrnul, podle me je nejlepsi vicevrstve zabezpeceni prave s HW oddelenim jednotlivych vrstev komunikace. Ja jsem zvolil tuto kombinaci, samozrejme je mozne pouzit treba prave WPA2 s AES, ale tam prave chybi to HW odeleni jednotlivych vrstev a o veskerou autorizaci a sifrovani se stara jeden prvek, ktery ma omezeny vykon, rekneme si narovinu kolik poskytovatelu treba internetu pres Wi-Fi pouziva profesionalni prvky.
Pakování zapakovaného (u běžnejch kompresí - LZA77, LZW...) trvá naopak kratší dobu - protože na jednou zapakovaný věci už není co pakovat. Schválně si to zkus (vzít např. stejně velkej obrázek a texťák) a prohnat zipem (sám jsem si to teď ověřil - dokonce rozdíl byl větší než jsem čekal, očekával jsem spíš stejný časy, ale zapakovat texťák trvá víc než dvojnásobek).
Takže nejsem tupej, jen prostě vim něco o kompresních algoritmech a tak jsem jaksi nemoh chápat relevanci, která tam neni.
Co se týče rozložení zátěže - většina lidí má doma např. AP, kterej zároveň funguje jako router. Takže tam to AP prostě musí počítat zároveň WEP a VPN. Samozřejmě pokud máš dvě krabičky za sebou, tak zátěž roložíš, ale pak ti zas můžou vzrůstat latence, protože ta krabička uprostřed to musí dešifrovat a pak to teprv poslat dál gatewayi, která to dešifruje znova, nemluvě o zbytečnym účtu za elektřinu. (To samozřejmě neplatí, pokud někdo provozuje jako gateway plnohodnotnej server - pak je ale zas otázka, není-li lepší jako AP udělat rovnou ten server a vykašlat se na router).
Navíc WPE je ochrana fakt iluzorní - to už Ti stačí skrýt SSID. Kdo se do tý sítě bude chtít dostat, tak se dostane.
Co se týče rychlosti sítě, udělal jsem teď test stolní PC - Gigabit switch - Asus WL500g Deluxe - Notebook (Intel Pro/Wireless 2200BG network adapter). Poprve nastaveno na WPA2/AES, podruhý bez zabezpečení.
Ping byl v obou případech 1ms, propustnost sítě následující:
TCP connection established.
Packet size 1k bytes: 2053 KByte/s Tx, 2255 KByte/s Rx.
Packet size 2k bytes: 2249 KByte/s Tx, 2241 KByte/s Rx.
Packet size 4k bytes: 2665 KByte/s Tx, 2717 KByte/s Rx.
Packet size 8k bytes: 2726 KByte/s Tx, 2717 KByte/s Rx.
Packet size 16k bytes: 2744 KByte/s Tx, 2670 KByte/s Rx.
Packet size 32k bytes: 2746 KByte/s Tx, 2736 KByte/s Rx.
Done.
C:\temp>win32-i386.exe -t 192.168.2.130
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 2046 KByte/s Tx, 2171 KByte/s Rx.
Packet size 2k bytes: 1963 KByte/s Tx, 2130 KByte/s Rx.
Packet size 4k bytes: 2119 KByte/s Tx, 2531 KByte/s Rx.
Packet size 8k bytes: 2256 KByte/s Tx, 2465 KByte/s Rx.
Packet size 16k bytes: 2301 KByte/s Tx, 2404 KByte/s Rx.
Packet size 32k bytes: 2310 KByte/s Tx, 2539 KByte/s Rx.
Done.
Pokud jsi měl ping 80ms, tak si měl něco určitě špatně, to je poměrně nehorázná doba na připojení k internetu, natož na lokální (byť bezdrátovou) síť. Navíc ping má natolik malej datovej tok, že ho
nemůže žádná WPA2 rozhodit (pokud by router nestíhal WPA2 šifrovat ping, jak by vypadal reálnej
provoz např při kopírování souboru???). Takže podle mě si měl něco jinýho špatně a vyvodil si z toho
blbý závěry.
Btw. ten muj asus, na kterym sem to testoval, má naprosto totožnej čipset (a procesor) jako ostatní
dnes prodávaný routery. (viz např. tabulka u firmware Openrwt s podporou hardware).
PS: Upozorňuju, že první hodnoty testu jsou s WPA2, druhý bez! Vzdálenost routeru k notebooku 1 metr, okolo tři sítě na kanálu jedna, používanej kanáů 11.
Takže nejsem tupej, jen prostě vim něco o kompresních algoritmech a tak jsem jaksi nemoh chápat relevanci, která tam neni.
Co se týče rozložení zátěže - většina lidí má doma např. AP, kterej zároveň funguje jako router. Takže tam to AP prostě musí počítat zároveň WEP a VPN. Samozřejmě pokud máš dvě krabičky za sebou, tak zátěž roložíš, ale pak ti zas můžou vzrůstat latence, protože ta krabička uprostřed to musí dešifrovat a pak to teprv poslat dál gatewayi, která to dešifruje znova, nemluvě o zbytečnym účtu za elektřinu. (To samozřejmě neplatí, pokud někdo provozuje jako gateway plnohodnotnej server - pak je ale zas otázka, není-li lepší jako AP udělat rovnou ten server a vykašlat se na router).
Navíc WPE je ochrana fakt iluzorní - to už Ti stačí skrýt SSID. Kdo se do tý sítě bude chtít dostat, tak se dostane.
Co se týče rychlosti sítě, udělal jsem teď test stolní PC - Gigabit switch - Asus WL500g Deluxe - Notebook (Intel Pro/Wireless 2200BG network adapter). Poprve nastaveno na WPA2/AES, podruhý bez zabezpečení.
Ping byl v obou případech 1ms, propustnost sítě následující:
TCP connection established.
Packet size 1k bytes: 2053 KByte/s Tx, 2255 KByte/s Rx.
Packet size 2k bytes: 2249 KByte/s Tx, 2241 KByte/s Rx.
Packet size 4k bytes: 2665 KByte/s Tx, 2717 KByte/s Rx.
Packet size 8k bytes: 2726 KByte/s Tx, 2717 KByte/s Rx.
Packet size 16k bytes: 2744 KByte/s Tx, 2670 KByte/s Rx.
Packet size 32k bytes: 2746 KByte/s Tx, 2736 KByte/s Rx.
Done.
C:\temp>win32-i386.exe -t 192.168.2.130
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 2046 KByte/s Tx, 2171 KByte/s Rx.
Packet size 2k bytes: 1963 KByte/s Tx, 2130 KByte/s Rx.
Packet size 4k bytes: 2119 KByte/s Tx, 2531 KByte/s Rx.
Packet size 8k bytes: 2256 KByte/s Tx, 2465 KByte/s Rx.
Packet size 16k bytes: 2301 KByte/s Tx, 2404 KByte/s Rx.
Packet size 32k bytes: 2310 KByte/s Tx, 2539 KByte/s Rx.
Done.
Pokud jsi měl ping 80ms, tak si měl něco určitě špatně, to je poměrně nehorázná doba na připojení k internetu, natož na lokální (byť bezdrátovou) síť. Navíc ping má natolik malej datovej tok, že ho
nemůže žádná WPA2 rozhodit (pokud by router nestíhal WPA2 šifrovat ping, jak by vypadal reálnej
provoz např při kopírování souboru???). Takže podle mě si měl něco jinýho špatně a vyvodil si z toho
blbý závěry.
Btw. ten muj asus, na kterym sem to testoval, má naprosto totožnej čipset (a procesor) jako ostatní
dnes prodávaný routery. (viz např. tabulka u firmware Openrwt s podporou hardware).
PS: Upozorňuju, že první hodnoty testu jsou s WPA2, druhý bez! Vzdálenost routeru k notebooku 1 metr, okolo tři sítě na kanálu jedna, používanej kanáů 11.
Taktiež mi nie je jasná uvádzaná odozva, ktorá sa mi zdá veľmi vysoká. Také hodnoty dosahujem, ak pingujem napr. google.com a ICMP paket vytvorí linux, ten ho pošle cez bridge na WMware, ktorý mi beží pod Windows XP SP2, ďalej jeho cesta putuje cez vzduch k 12 metrov vzdialenému AP (DSL modem/wifi router), prechodom cez 40 cm panelovú stenu, router ho predá cez PPP na smerovač môjho providera, atď.
Výpis prikladám... a dodám, že používam WPA2+AES, singál je takmer plný, no rýchlosť je redukovaná z 54 Mbit/s na 5.5 Mbit/s.
:rules[code]
eraser@linux-eraser:~> ping -c 10 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=4.91 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=4.20 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=4.35 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.98 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=4.31 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=3.16 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=4.38 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=2.77 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=5.78 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3.10 ms
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 2.772/3.997/5.788/0.922 ms
eraser@linux-eraser:~> su root
Password:
linux-eraser:/home/eraser # traceroute www.google.com
traceroute to www.google.com (74.125.39.99), 30 hops max, 40 byte packets
1 . (192.168.1.1) 3.515 ms 10.090 ms 11.576 ms
2 213.81.232.217 (213.81.232.217) 44.558 ms 57.266 ms 58.852 ms
3 213.81.249.201 (213.81.249.201) 61.660 ms 57.772 ms 60.662 ms
4 babo85.213-81-254.telecom.sk (213.81.254.85) 70.754 ms 74.339 ms 72.526 ms
5 84.233.184.98 (84.233.184.98) 70.444 ms 69.224 ms 92.168 ms
6 PO14-0.bts-001-access-100.interoute.net (84.233.184.97) 20.808 ms 18.197 ms 17.579 ms
7 Gi5-0-0.vie-per-access-1.interoute.net (84.233.147.46) 23.205 ms 22.247 ms 22.491 ms
8 Gi11-0-0.vie-per-access-3.interoute.net (212.23.43.42) 21.921 ms 22.125 ms 31.544 ms
9 Gi5-0-0.prg-001-access-100.interoute.net (212.23.43.46) 36.056 ms 24.967 ms 23.727 ms
10 Gi6-0-0.prg-001-access-300.interoute.net (212.23.50.118) 26.461 ms 25.877 ms 23.957 ms
11 PO2-0.prg-001-inter-1.interoute.net (212.23.50.86) 24.751 ms 23.310 ms 29.538 ms
12 84.233.160.238 (84.233.160.238) 29.120 ms 36.332 ms 23.369 ms
13 209.85.250.228 (209.85.250.228) 20.317 ms 24.522 ms 21.582 ms
14 209.85.250.232 (209.85.250.232) 28.651 ms 31.498 ms 33.200 ms
15 209.85.254.112 (209.85.254.112) 31.273 ms 29.305 ms 209.85.254.118 (209.85.254.118) 83.613 ms
16 209.85.254.134 (209.85.254.134) 94.250 ms 209.85.254.126 (209.85.254.126) 112.625 ms 133.460 ms
17 www.l.google.com (74.125.39.99) 116.674 ms 118.702 ms 117.275 ms
linux-eraser:/home/eraser #
eraser@linux-eraser:~> ping -c 5 www.google.com
PING www.google.com (74.125.39.99) 56(84) bytes of data.
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=1 ttl=243 time=30.2 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=2 ttl=243 time=32.6 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=3 ttl=243 time=34.4 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=4 ttl=243 time=32.8 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=5 ttl=243 time=33.9 ms
--- www.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4009ms
rtt min/avg/max/mdev = 30.260/32.852/34.450/1.457 ms
[/code]
Výpis prikladám... a dodám, že používam WPA2+AES, singál je takmer plný, no rýchlosť je redukovaná z 54 Mbit/s na 5.5 Mbit/s.
:rules[code]
eraser@linux-eraser:~> ping -c 10 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=4.91 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=4.20 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=4.35 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.98 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=4.31 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=3.16 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=4.38 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=2.77 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=5.78 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3.10 ms
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 2.772/3.997/5.788/0.922 ms
eraser@linux-eraser:~> su root
Password:
linux-eraser:/home/eraser # traceroute www.google.com
traceroute to www.google.com (74.125.39.99), 30 hops max, 40 byte packets
1 . (192.168.1.1) 3.515 ms 10.090 ms 11.576 ms
2 213.81.232.217 (213.81.232.217) 44.558 ms 57.266 ms 58.852 ms
3 213.81.249.201 (213.81.249.201) 61.660 ms 57.772 ms 60.662 ms
4 babo85.213-81-254.telecom.sk (213.81.254.85) 70.754 ms 74.339 ms 72.526 ms
5 84.233.184.98 (84.233.184.98) 70.444 ms 69.224 ms 92.168 ms
6 PO14-0.bts-001-access-100.interoute.net (84.233.184.97) 20.808 ms 18.197 ms 17.579 ms
7 Gi5-0-0.vie-per-access-1.interoute.net (84.233.147.46) 23.205 ms 22.247 ms 22.491 ms
8 Gi11-0-0.vie-per-access-3.interoute.net (212.23.43.42) 21.921 ms 22.125 ms 31.544 ms
9 Gi5-0-0.prg-001-access-100.interoute.net (212.23.43.46) 36.056 ms 24.967 ms 23.727 ms
10 Gi6-0-0.prg-001-access-300.interoute.net (212.23.50.118) 26.461 ms 25.877 ms 23.957 ms
11 PO2-0.prg-001-inter-1.interoute.net (212.23.50.86) 24.751 ms 23.310 ms 29.538 ms
12 84.233.160.238 (84.233.160.238) 29.120 ms 36.332 ms 23.369 ms
13 209.85.250.228 (209.85.250.228) 20.317 ms 24.522 ms 21.582 ms
14 209.85.250.232 (209.85.250.232) 28.651 ms 31.498 ms 33.200 ms
15 209.85.254.112 (209.85.254.112) 31.273 ms 29.305 ms 209.85.254.118 (209.85.254.118) 83.613 ms
16 209.85.254.134 (209.85.254.134) 94.250 ms 209.85.254.126 (209.85.254.126) 112.625 ms 133.460 ms
17 www.l.google.com (74.125.39.99) 116.674 ms 118.702 ms 117.275 ms
linux-eraser:/home/eraser #
eraser@linux-eraser:~> ping -c 5 www.google.com
PING www.google.com (74.125.39.99) 56(84) bytes of data.
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=1 ttl=243 time=30.2 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=2 ttl=243 time=32.6 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=3 ttl=243 time=34.4 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=4 ttl=243 time=32.8 ms
64 bytes from www.l.google.com (74.125.39.99): icmp_seq=5 ttl=243 time=33.9 ms
--- www.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4009ms
rtt min/avg/max/mdev = 30.260/32.852/34.450/1.457 ms
[/code]
Obe uvedena mereni jsou spojeni kde je jeden klient a jeden router bezdratove. Vsimnete si ze ty propustnosti jsou cca dvojnasobne, nez uvadim ja a vzhledem k tomu, ze mate zarizeni relativne blizko u sebe a nedochazi vubec ke kolizim a preslechum tak mate nadherny ping.
Radeji ZDURAZNUJU, ze uvedene hodnoty plati pro wi-fi komunikaci klient1 - router - klient2, tudiz pokud je vse idealne nastaveno, jede sit ciste G a jsou spravne nastavene tresholdy, tak se dostaneme s rychlosti na tech cca 1200 kB/sec.
Nemluve o tom ze se tam muze vyskytnout az 6 klientu najednou.
Pri nastaveni WEP 128 a souctu vzdalenosti mezi klienty a routerem kolem 200m, se ping drzi na 8-10 ms pri neprilis velkem prenosu dat. Na plno tedy pri prenosu kolem 1200kB/sec se ping drzi pod hodnotou 30ms.
No a kdyz tam nahodim WPA2 a zatizim to stejne, dostanu ping ve vykyvech az na 100ms, po zkusenostech to delaji skoro vsechny routery.
To je to o cem jsem psal a duvod proc pouzivam nastaveni ktere pouzivam.
Jinak veskera nastaveni Wi-fi jsou spravna, overena merenim a nastavena na veskerych zarizenich stejne, co by se dalo jeste zvednout je vykon, cimz by se pravdepodobne zmensil pocet chyb a preslechu, ale ne tak vyrazne aby to stalo za to.
Logout: fakt uz jsem nechtel reagovat sakrys ale neda mi to
100 MB avi video komprese ZIP - Deflate 32kB 32B slovo program 7-zip 2 jadra slovnik rychlosti cca 6000 kB/sec, opakovana komprese totez nastaveni rychlost 1500 kB/sec
Komprese funguje na zaklade vyhledavani slov a jejich sekvencni nahrazovani, cim hure je soubor komprimovatelny, dim dele trva hledani slova pro prislusny blok a tim vetsi cast slovniku se projede, pripadne prida.
Samozrejme zalezi na metode komprese, ale ty nejrozsirenejsi pracuji takto, ale pokud to tak necitis je o jedno, podstatna je prvotni myslenka ze sifrovani zasifrovaneho je stejne narocne, narozdil od pakovani jiz zapakovaneho ktere je JINAK narocne a je jedno jestli mene nebo vice.
Kompresni algorytmus je adaptabilni a pouziva slovniky, narozdil od sifrovaciho algorytmu ktery je "konstatni".
Radeji ZDURAZNUJU, ze uvedene hodnoty plati pro wi-fi komunikaci klient1 - router - klient2, tudiz pokud je vse idealne nastaveno, jede sit ciste G a jsou spravne nastavene tresholdy, tak se dostaneme s rychlosti na tech cca 1200 kB/sec.
Nemluve o tom ze se tam muze vyskytnout az 6 klientu najednou.
Pri nastaveni WEP 128 a souctu vzdalenosti mezi klienty a routerem kolem 200m, se ping drzi na 8-10 ms pri neprilis velkem prenosu dat. Na plno tedy pri prenosu kolem 1200kB/sec se ping drzi pod hodnotou 30ms.
No a kdyz tam nahodim WPA2 a zatizim to stejne, dostanu ping ve vykyvech az na 100ms, po zkusenostech to delaji skoro vsechny routery.
To je to o cem jsem psal a duvod proc pouzivam nastaveni ktere pouzivam.
Jinak veskera nastaveni Wi-fi jsou spravna, overena merenim a nastavena na veskerych zarizenich stejne, co by se dalo jeste zvednout je vykon, cimz by se pravdepodobne zmensil pocet chyb a preslechu, ale ne tak vyrazne aby to stalo za to.
Logout: fakt uz jsem nechtel reagovat sakrys ale neda mi to
100 MB avi video komprese ZIP - Deflate 32kB 32B slovo program 7-zip 2 jadra slovnik rychlosti cca 6000 kB/sec, opakovana komprese totez nastaveni rychlost 1500 kB/sec
Komprese funguje na zaklade vyhledavani slov a jejich sekvencni nahrazovani, cim hure je soubor komprimovatelny, dim dele trva hledani slova pro prislusny blok a tim vetsi cast slovniku se projede, pripadne prida.
Samozrejme zalezi na metode komprese, ale ty nejrozsirenejsi pracuji takto, ale pokud to tak necitis je o jedno, podstatna je prvotni myslenka ze sifrovani zasifrovaneho je stejne narocne, narozdil od pakovani jiz zapakovaneho ktere je JINAK narocne a je jedno jestli mene nebo vice.
Kompresni algorytmus je adaptabilni a pouziva slovniky, narozdil od sifrovaciho algorytmu ktery je "konstatni".
Preto je dôležité uvádzať presné informácie jasne a zrozumiteľne hneď na začiatku. Tiež by som asi neuspel, keby som uvádzal nejaké benchmarky grafických kariet a pritom neuviedol presný popis konfigurácie, na ktorej som tak učinil.
Inak algoritmus sa píše s mäkkým i. :)
Inak algoritmus sa píše s mäkkým i. :)
Přes WPA2 projdou jen ty ramce, ktery vubec po linkovy vrstve prosly. Takze pripadny kolize rozhodne nebudou WPA2 zpomalovat, spis naopak - o kazdou kolizi vic ma procesor, kterej WPA2 pocita, min prace, protoze datovej tok je mensi. Navic, pokud by bylo příčinou zpomalení WPA2 kolize, tak by ke stejnému zpomalení došlo i u spojení bez WPA2. Takže rozhodně nižší výkon WPA2 nemůže bejt způsobenej kolizema.
Výkon WPA při obou připojenejch přes WPA2
TCP connection established.
Packet size 1k bytes: 1336 KByte/s Tx, 1120 KByte/s Rx.
Packet size 2k bytes: 1184 KByte/s Tx, 1207 KByte/s Rx.
Packet size 4k bytes: 1237 KByte/s Tx, 1037 KByte/s Rx.
Packet size 8k bytes: 1283 KByte/s Tx, 1262 KByte/s Rx.
Packet size 16k bytes: 1306 KByte/s Tx, 1272 KByte/s Rx.
Packet size 32k bytes: 1288 KByte/s Tx, 1294 KByte/s Rx.
Done.
C:\temp>ping 192.168.2.130
Pinging 192.168.2.130 with 32 bytes of data:
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
WPA2, připojený dva bezdrátový klienti (ntb viz minule + MSI USB klíčenka 802.11g Wireless USB2.0 Adapter, víc o tom teď tychle nejsem schopnej zjistit). Ping 1ms, výkon na polovině výkonu sítě. Nevidim kde by měl bejt ten problém s WPA2 a poklesem výkonu. Při vypnutí WPA2 jsem dostal naprosto stejný čísla.
Totéž nastalo, když jsem odnes ntb na druhou stranu vcelku velkýho bytu - přímou čarou přes čtyři zdi (první čísla bez WPA, druhý s WPA):
TCP connection established.
Packet size 1k bytes: 937 KByte/s Tx, 397 KByte/s Rx.
Packet size 2k bytes: 850 KByte/s Tx, 418 KByte/s Rx.
Packet size 4k bytes: 891 KByte/s Tx, 412 KByte/s Rx.
Packet size 8k bytes: 873 KByte/s Tx, 573 KByte/s Rx.
Packet size 16k bytes: 855 KByte/s Tx, 249 KByte/s Rx.
Packet size 32k bytes: 956 KByte/s Tx, 262 KByte/s Rx.
Done.
C:\temp>win32-i386.exe -t 192.168.2.130
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 929 KByte/s Tx, 466 KByte/s Rx.
Packet size 2k bytes: 745 KByte/s Tx, 387 KByte/s Rx.
Packet size 4k bytes: 807 KByte/s Tx, 385 KByte/s Rx.
Packet size 8k bytes: 801 KByte/s Tx, 386 KByte/s Rx.
Packet size 16k bytes: 863 KByte/s Tx, 554 KByte/s Rx.
Packet size 32k bytes: 849 KByte/s Tx, 516 KByte/s Rx.
Done.
C:\temp>ping 192.168.2.130
Pinging 192.168.2.130 with 32 bytes of data:
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Tak se prostě zamysli, kde si předtim udělal chybu - ten muj router používá stejnej chipset jako drtivá většina ostatních routerů.
Co se týče komprese, tak tam to evidentně záleží na algoritmu.
zdroj: http://www.techarp.com/showarticle.aspx?artno=4&pgno=2
WAV má malou entropii. mp3 je ji zpakovaný s entropií skoro jedna. Evidentně zip, kterej jsem poukazoval já (zde teda gzip, používá podobnej algoritmus) má radši již komprimovaný data, 7zip spíš nekomprimovaný (ve svejch domácích testech jsem zaznamenal rozdíl cca 10% - těch tvejch 400% muselo bejt špatnou metodikou, např. různě volenou dýlkou souboru nebo čím - ani já, ani tendle server takovej rozdíl nenaměřil).
Rozhodně se však evidentně nedá říct, že vlastnost komprese je, že jednou zpakovaný data se pakujou dýl - zjevně záleží na algoritmu a i na vstupních datech. (a to neberu v úvahu, že pakováním se data zmenší, čili další pakování trvá méně času, protože má méně dat).
Naprosto však nechápu Tvoje zdůvodnění. Slovník se rozhodně neprohledává sekvenčně, nýbrž to je bývá v běžnejch implementacích kompresních algoritmů strom (viz skripta na mff k tušim datovejm strukturám, nechce se mi to teď hledat) - a tam rozhodně neúspěch při vyhledávání časově náročnější než úspěch. Pokud by se do stromu ukládaly vždy stejně dlouhá slova (což se ale u mě známejch algoritmů neděje), tak by byl neúspěch dokonce kratší - pro úspěch se musí projít celej strom až do poslední úrovně, zatímco při neúspěchu se může neuspět v kterékoli úrovni stromu.
Výkon WPA při obou připojenejch přes WPA2
TCP connection established.
Packet size 1k bytes: 1336 KByte/s Tx, 1120 KByte/s Rx.
Packet size 2k bytes: 1184 KByte/s Tx, 1207 KByte/s Rx.
Packet size 4k bytes: 1237 KByte/s Tx, 1037 KByte/s Rx.
Packet size 8k bytes: 1283 KByte/s Tx, 1262 KByte/s Rx.
Packet size 16k bytes: 1306 KByte/s Tx, 1272 KByte/s Rx.
Packet size 32k bytes: 1288 KByte/s Tx, 1294 KByte/s Rx.
Done.
C:\temp>ping 192.168.2.130
Pinging 192.168.2.130 with 32 bytes of data:
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
WPA2, připojený dva bezdrátový klienti (ntb viz minule + MSI USB klíčenka 802.11g Wireless USB2.0 Adapter, víc o tom teď tychle nejsem schopnej zjistit). Ping 1ms, výkon na polovině výkonu sítě. Nevidim kde by měl bejt ten problém s WPA2 a poklesem výkonu. Při vypnutí WPA2 jsem dostal naprosto stejný čísla.
Totéž nastalo, když jsem odnes ntb na druhou stranu vcelku velkýho bytu - přímou čarou přes čtyři zdi (první čísla bez WPA, druhý s WPA):
TCP connection established.
Packet size 1k bytes: 937 KByte/s Tx, 397 KByte/s Rx.
Packet size 2k bytes: 850 KByte/s Tx, 418 KByte/s Rx.
Packet size 4k bytes: 891 KByte/s Tx, 412 KByte/s Rx.
Packet size 8k bytes: 873 KByte/s Tx, 573 KByte/s Rx.
Packet size 16k bytes: 855 KByte/s Tx, 249 KByte/s Rx.
Packet size 32k bytes: 956 KByte/s Tx, 262 KByte/s Rx.
Done.
C:\temp>win32-i386.exe -t 192.168.2.130
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 929 KByte/s Tx, 466 KByte/s Rx.
Packet size 2k bytes: 745 KByte/s Tx, 387 KByte/s Rx.
Packet size 4k bytes: 807 KByte/s Tx, 385 KByte/s Rx.
Packet size 8k bytes: 801 KByte/s Tx, 386 KByte/s Rx.
Packet size 16k bytes: 863 KByte/s Tx, 554 KByte/s Rx.
Packet size 32k bytes: 849 KByte/s Tx, 516 KByte/s Rx.
Done.
C:\temp>ping 192.168.2.130
Pinging 192.168.2.130 with 32 bytes of data:
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Reply from 192.168.2.130: bytes=32 time=1ms TTL=128
Tak se prostě zamysli, kde si předtim udělal chybu - ten muj router používá stejnej chipset jako drtivá většina ostatních routerů.
Co se týče komprese, tak tam to evidentně záleží na algoritmu.
zdroj: http://www.techarp.com/showarticle.aspx?artno=4&pgno=2
WAV má malou entropii. mp3 je ji zpakovaný s entropií skoro jedna. Evidentně zip, kterej jsem poukazoval já (zde teda gzip, používá podobnej algoritmus) má radši již komprimovaný data, 7zip spíš nekomprimovaný (ve svejch domácích testech jsem zaznamenal rozdíl cca 10% - těch tvejch 400% muselo bejt špatnou metodikou, např. různě volenou dýlkou souboru nebo čím - ani já, ani tendle server takovej rozdíl nenaměřil).
Rozhodně se však evidentně nedá říct, že vlastnost komprese je, že jednou zpakovaný data se pakujou dýl - zjevně záleží na algoritmu a i na vstupních datech. (a to neberu v úvahu, že pakováním se data zmenší, čili další pakování trvá méně času, protože má méně dat).
Naprosto však nechápu Tvoje zdůvodnění. Slovník se rozhodně neprohledává sekvenčně, nýbrž to je bývá v běžnejch implementacích kompresních algoritmů strom (viz skripta na mff k tušim datovejm strukturám, nechce se mi to teď hledat) - a tam rozhodně neúspěch při vyhledávání časově náročnější než úspěch. Pokud by se do stromu ukládaly vždy stejně dlouhá slova (což se ale u mě známejch algoritmů neděje), tak by byl neúspěch dokonce kratší - pro úspěch se musí projít celej strom až do poslední úrovně, zatímco při neúspěchu se může neuspět v kterékoli úrovni stromu.
Hele delas ten ping zaroven s prenosem??
je jen ze se ti to drzi na 1ms coz je dobrej vykon i na zatizenou metalickou sit.
Je fakt, ze tenhle ASUS podle ohlasu vytahne z toho Broadcomu co se da a s openWRT je z toho plnohodnotnej router, ale nejak nemuzu uverit, ze by dokazal zazraky v podobe 1ms pingu kdyz je jako bridge mezi dvema bezdratovymi klienty.
Jeste pro doplneni informaci, aktualne delam pro UPC internety a pod. a setkavam se s velkym mnozstvim ruznych routeru a pod.
A co se tyka wi-fi tak jsme delali strukturu fogelnet jeste kdyz byla na 2,4 GHz, tam jsme nakonec skoncili u uplne nesifrovane komunikace, stejne jako vetsina ostatnich poskytovatelu, prekvapive prave kvuli narocnosti na vykon prvku. A sit jsme uzavreli jinymi metodami.
Jo a prosimte, OPAKOVANA komprese, ne to co mas v te tabulce, bavim se o opakovane bezeztratove kompresi. Ale ANO MAS PRAVDU ZALEZI NA ALGORYTMU (eraser-pouzivam pocestenou verzi s Y)
je jen ze se ti to drzi na 1ms coz je dobrej vykon i na zatizenou metalickou sit.
Je fakt, ze tenhle ASUS podle ohlasu vytahne z toho Broadcomu co se da a s openWRT je z toho plnohodnotnej router, ale nejak nemuzu uverit, ze by dokazal zazraky v podobe 1ms pingu kdyz je jako bridge mezi dvema bezdratovymi klienty.
Jeste pro doplneni informaci, aktualne delam pro UPC internety a pod. a setkavam se s velkym mnozstvim ruznych routeru a pod.
A co se tyka wi-fi tak jsme delali strukturu fogelnet jeste kdyz byla na 2,4 GHz, tam jsme nakonec skoncili u uplne nesifrovane komunikace, stejne jako vetsina ostatnich poskytovatelu, prekvapive prave kvuli narocnosti na vykon prvku. A sit jsme uzavreli jinymi metodami.
Jo a prosimte, OPAKOVANA komprese, ne to co mas v te tabulce, bavim se o opakovane bezeztratove kompresi. Ale ANO MAS PRAVDU ZALEZI NA ALGORYTMU (eraser-pouzivam pocestenou verzi s Y)
Ping nedělam zároveň s přenosem. Je jasný, že když mám vzduch plnej dat, tak se tam ten ping procpe dost blbě. Jestlis myslel ping v plně zatížený síti, taks to měl říct, to je trochu jiná polívka. Tam je ale to čekání IMHO způsobený tim, že když se prostě zrovna rozhodne PC pingnout, tak pravědpodobně vysílá, čili musí počkat, až se vzduch uvolní.
Při plný zátěži (zároveň je spuštěnej ten benchmark netio) v obou případech pingy kolísaj mezi 20ms-110ms bez rozdílu v zabezpečení. Ale takhle vysokej ping je imho logickej patřičnej packet stojí prostě ve frontě...
Co se týče komprese - tak mp3 je sice ztrátová komprese, ale každá ztrátová komprese funguje víceméně tak, že se s datama něco udělá, aby šly snadno vyházet méně podstatný transformace (FFT, různý wawelet transformace, jiný kódování vhodnější ke kompresi (jpg) apod.), vyházej se nepostatný informace a nakonec se to bezztrátově zkomprimuje. Takže i u mp3 jde o opakovanou bezztrátovou kompresi.
PS: Pak sis to ale počeštil sám, protože slovník spisovný češtiny zná pouze variantu s měkym i....
Při plný zátěži (zároveň je spuštěnej ten benchmark netio) v obou případech pingy kolísaj mezi 20ms-110ms bez rozdílu v zabezpečení. Ale takhle vysokej ping je imho logickej patřičnej packet stojí prostě ve frontě...
Co se týče komprese - tak mp3 je sice ztrátová komprese, ale každá ztrátová komprese funguje víceméně tak, že se s datama něco udělá, aby šly snadno vyházet méně podstatný transformace (FFT, různý wawelet transformace, jiný kódování vhodnější ke kompresi (jpg) apod.), vyházej se nepostatný informace a nakonec se to bezztrátově zkomprimuje. Takže i u mp3 jde o opakovanou bezztrátovou kompresi.
PS: Pak sis to ale počeštil sám, protože slovník spisovný češtiny zná pouze variantu s měkym i....
Tak to je pak jasny ze se nemuzeme schodnout na hodnotach.
Kdyz si das jeste tu praci ze sit zatizis tak tokem 500kB/sec s vice bezdratovych zdroju, zkus alespon 3, tak konecne uvidis ty rozdily mezi WEP a WPA a kdyby nahodou ne tak pak uz me napada jen ze ten tvuj Broadcom je podstatne lepsi nez ty Realtek na kterych jsem to primarne zkousel ja.
OT: to Y jsem si nevymyslel uplne sam, je nas vic a vzhledem k vyvoji jazyka tomu davam tak 5 let nez se to rozsiri a budou mozne obe moznosti.
Kdyz si das jeste tu praci ze sit zatizis tak tokem 500kB/sec s vice bezdratovych zdroju, zkus alespon 3, tak konecne uvidis ty rozdily mezi WEP a WPA a kdyby nahodou ne tak pak uz me napada jen ze ten tvuj Broadcom je podstatne lepsi nez ty Realtek na kterych jsem to primarne zkousel ja.
OT: to Y jsem si nevymyslel uplne sam, je nas vic a vzhledem k vyvoji jazyka tomu davam tak 5 let nez se to rozsiri a budou mozne obe moznosti.
No, zatizeny to bylo max co to jde, takze 1300KB/s odesilat a prijimat. A ping byl u WPA2 a bez zabezpeceni naprosto stejnej. Broadcomy maj dneska snad vsechny routery - viz tabulka kompatibilniho hardware Openwrt.
Víc bezdrátovejch klientů než dva doma nemám, až se mi sejdou, tak to třeba zkusím :-).
OT: Doufam že ne, mam češtinu rád... :-)
Víc bezdrátovejch klientů než dva doma nemám, až se mi sejdou, tak to třeba zkusím :-).
OT: Doufam že ne, mam češtinu rád... :-)
Zkus to zatizit mene nez na maximum, vygeneruj takovy bezny traffic.
Ono kdyz to zatizis velkymi a hlavne stale stejnymi pakety na maximum propustnosti 1 vrstvy, tak to moc nevypovida a ten ping proste visi kolem maxima.
Jinak jsem protahnul google a Wiki, ten broadcom ma asi fakt kvalitnejsi chipsety, ta rozsirenost je relativni, ale o vykonu se pise dost.
Hlavne oproti treba memu Realteku se nedostane na 50 stupnu (a to tam mam pasiv), akorat jsem si zvyknul na APPro, ma proti OpenWRT vyhodu ve zvlasni flashce na modulu, coz je idealni na ladeni konfigurace a tak.
Ono kdyz to zatizis velkymi a hlavne stale stejnymi pakety na maximum propustnosti 1 vrstvy, tak to moc nevypovida a ten ping proste visi kolem maxima.
Jinak jsem protahnul google a Wiki, ten broadcom ma asi fakt kvalitnejsi chipsety, ta rozsirenost je relativni, ale o vykonu se pise dost.
Hlavne oproti treba memu Realteku se nedostane na 50 stupnu (a to tam mam pasiv), akorat jsem si zvyknul na APPro, ma proti OpenWRT vyhodu ve zvlasni flashce na modulu, coz je idealni na ladeni konfigurace a tak.
No a jak to teda mam zatížit? Tři WIFI klienty tu nemam, zkusil jsem teda na dvou klientech při zapnutym WPA2 dát kopírování TEX tree (hromada malejch souborů). Ping pořád 1ms s občasnejma výjímečnějma (1 ping z deseti, později z 50) skokama vejš (2-20ms). Pokud se do toho zapojilo kopírování velkýho souboru
(tzn. tři simultání kopírování), ping se začal pohybovat na 13-20ms při rychlosti kopírování (toho jednoho souboru) kolem 400kB/s (což vzhledem k tomu, že kolem běžej další dvě kopírování a maximum co jde ze sítě dostat je 1300kb/s považuju za slušný). Zkoušet to bez WPA2 se mi moc nechce, nemyslim, že bych dostal lepší hodnoty.
Jak by se to chovalo, kdybych zapojil třeba deset nebo patnáct klientů nevim - pro ISP, kterej má rozesetý APčka a pak někde centrální server, kterej řeší VPN, je možný, že ty APčka ten WEP řešej rychlejc - ale při domácí použití, kde je typickou zátěží komunikace jednoho klienta s drátovou částí sítě, max komunikace dvou wifi klientů, IMHO WPA2 vliv na výkon APčka (alespoň broadcomu) nemá.
Co se týče chipsetů - tak neni myslím náhoda, že asusy a linksysy jsou jedny z nejoblíbenější routerů.
Na US robotics jsem taky slyšel jen dobrý...
(tzn. tři simultání kopírování), ping se začal pohybovat na 13-20ms při rychlosti kopírování (toho jednoho souboru) kolem 400kB/s (což vzhledem k tomu, že kolem běžej další dvě kopírování a maximum co jde ze sítě dostat je 1300kb/s považuju za slušný). Zkoušet to bez WPA2 se mi moc nechce, nemyslim, že bych dostal lepší hodnoty.
Jak by se to chovalo, kdybych zapojil třeba deset nebo patnáct klientů nevim - pro ISP, kterej má rozesetý APčka a pak někde centrální server, kterej řeší VPN, je možný, že ty APčka ten WEP řešej rychlejc - ale při domácí použití, kde je typickou zátěží komunikace jednoho klienta s drátovou částí sítě, max komunikace dvou wifi klientů, IMHO WPA2 vliv na výkon APčka (alespoň broadcomu) nemá.
Co se týče chipsetů - tak neni myslím náhoda, že asusy a linksysy jsou jedny z nejoblíbenější routerů.
Na US robotics jsem taky slyšel jen dobrý...
