Bezpečnost WiFi sítě

[Logout]

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

[slowak1982]

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.

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

[eraser]

Navíc WPE dneska jako kdyby nebylo (hacknutý je tuším cca za 10min)

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.

[Logout]

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.

[|Mio|]

Od tud je to OT:

....

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.

OD TUD 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.

[Logout]

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.

[eraser]

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.

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

[|Mio|]

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

[eraser]

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.

[Logout]

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.

[|Mio|]

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)

[Logout]

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

[|Mio|]

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.

[Logout]

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

[|Mio|]

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.