Dotaz: Problém s Atheros AR5213 na 2,4GHz - rychlost připojených klientů

[slim2]

Dobrý den,
mám server Debian Sarge, jadro 2.6.15. Řeším problém s miniPCI kartou Atheros 5213, která se hlásí v LX:

0000:01:0b.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

Bezdrátově mám připojené jen 3 klienty. Dříve jsem používál obyčejné AP Edimax, které fungovalo (rychlost 2-3MB/s - 802.11g), ale přeci jen se jednalo o levné AP a nebylo tak vybaveno.

Kartu provozuji na 2,4GHz a zkoušel jsem ji jak na 802.11b, tak i 802.11g + používám jen WEP a v shorewallu mám maclist a vždy je výsledek stejný:
Nahodím kartu a klienti se bez problémů připojí a rychlost přenosu v síti se pohybuje kolem 1,3MB/s. Ale asi po 5 minutách rychlost klesne někde k 60kB/s, což je velmi málo. Tohle nastane i při minimálním přenosu v síti.
Chování karty je jako by se přepnula do nějakého úsporného režimu, ze kterého ji probere jen restart zařízení (jen na 5min).
Děkuji za info.

Odpovědi

[Andrej]

Každopádně doporučuji důkladně prostudovat man iwconfig, man iwpriv a hlášky, které vypisuje iwlist.

Úsporné režimy se dají nastavit a možnosti nastavení jsou široké. V případě problémů je dobré veškeré šetření vypnout, což u access pointu platí dvojnásob. Zejména doporučuji iwconfig ethX power <parametr>, iwconfig ethX txpower <parametr>, iwpriv ethX get_power, iwlist ethX power, iwlist ethX txpower atd.

Taky je nutné udělat iwlist ethX scanning (několikrát na různých místech, nejlépe u všech zařízení). Co když je někdo na stejném kanále? To je potom všude beznadějný šum.

"Vidí" se všechna zařízení navzájem, nebo jen všechna vidí access point, ale vzájemně se vidět nemusí? Ve druhém případě musí být nutně zapnuté řízení toku RTS/CTS. V extrémně zašuměném prostředí je dokonce dobré používat fragmentované pakety.

Další příčiny můžou být různé, např. cyklus v routingu. Stokrát jsem si říkal, že takovou blbost nikdy neudělám, a přesto jsem ji už dvakrát udělal. To je pak přenosová rychlost k uzoufání. Nebo třeba nesprávně nastavené šifrování...

[slim2]

OK, díky moc. Sice jsem přesně nezjistil jak na řízení toku, ale přidal jsem:

iwconfig ath0 rts 300
iwconfig ath0 frag 300

Již dříve jsem měl:

iwconfig ath0 power off

Rozdíl jsem na síti poznal. Sice stále to není na 100% dobré, ale určitě lepší než předtím. Ještě přidávám výpis iwconfig:

ath0      IEEE 802.11g  ESSID:"xxxxxxxx"
          Mode:Master  Frequency:2.452 GHz  Access Point: 00:0B:6B:4D:8F:BB
          Bit Rate:0 kb/s   Tx-Power=13 dBm   Sensitivity=0/3
          Retry:off   RTS thr=300 B   Fragment thr=300 B
          Encryption key:xxxx-xxxx-xx   Security mode:restricted
          Power Management:off
          Link Quality=28/94  Signal level=-67 dBm  Noise level=-95 dBm
          Rx invalid nwid:349  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:3136  Invalid misc:3136   Missed beacon:0

[Andrej]

To by mělo být lepší, hlavně pokud je tam hodně šumu.

V tom výpisu ještě vidím Tx-Power 13 dBm. U některých zařízení je to maximum, jinde se dá zvýšit až na 20 dBm (limit daný zákonem). Je to iwconfig ath0 txpower nebo to jde taky nějak přes iwpriv.

Ještě se mi nezdá jedna věc: Hodnota retry se většinou nastavuje někde kolen 16 pokusů, v zarušeném prostředí i víc. (Pokud se nastavuje pomocí času, mělo by to být něco jako 100 milisekund, opět podle míry šumu.) Je to podrobně popsané v man iwconfig, dají se tam stanovit maxima i minima automatické konfigurace, časy i počty pokusů.

Dál sensitivity. Nevím přesně, co znamená 0/3, protože u mého ..zařízení se to nastavuje samo. V každém případě je potřeba ji nastavit tak, aby karta nepřijímala zbytečně šum. To znamená, že v tomto případě může pomoct (paradoxně) snížení citlivosti, tj. zvýšení prahu citlivosti.

Link quality 28/94 - to mluví za vše. Nevím, jestli je to běžný provoz nebo pokus, co to snese, ale v každém případě přikládám svůj výpis, hlavně se podívej na poslední dva řádky.

eth1      IEEE 802.11b  ESSID:"MojeSSID"  Nickname:"MůjNick"
          Mode:Managed  Frequency:2.447 GHz  Access Point: 00:30:F1:E6:0C:33
          Bit Rate=11 Mb/s   Tx-Power:16 dBm
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key: MůjSkvělýAStrašněDlouhýKlíč   Security mode:restricted
          Power Management:off
          Link Quality=100/100  Signal level=-42 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Rx invalid nwid: 349... To je kámen úrazu. podle mě je někdo na stejném kanále. Nebo máš celou síť nakonfigurovanou tak, že je rozdělená na dvě části a každá má třeba jiné šifrování, ale sdílejí stejný kanál. 2,452 GHz - to je kanál 9. Celkem je jich 14, takže zkus v okolí udělat měření pomocí iwlist a v případě potřeby to změň. Měl bys být vzdálený aspoň o 2 kanály od všech vysílačů, které dokážeš zachytit. (Toto je triviální - kanál změníš jen na access pointu a klienti si ho všichni sami najdou.)

Pokud se podaří dosáhnout rozumné rychlosti a spolehlivosti, je nakonec dobré vypnout fragmentaci. (Hodně zpomaluje a je opravdu jen pro nouzové případy.) Pokud měření ukáže, že klienti na sebe navzájem vidí, lze vypnout i RTS/CTS.

Tady je ještě výpis iwlist eth1 scanning. Je tam jen jeden (můj) access point, ale jakmile bych se přiblížil s notebookem k oknu, měl bych tam přinejmenším další čtyři. (Naštěstí na jiných kanálech.)

eth1      Scan completed :
          Cell 01 - Address: 00:30:F1:E6:0C:33
                    ESSID:"MojeSSID"
                    Protocol:IEEE 802.11bg
                    Mode:Master
                    Channel:8
                    Encryption key:on
                    Bit Rate:54 Mb/s
                    Extra: Rates (Mb/s): 1 2 5.5 6 9 11 12 18 22 24 36 48 54
                    Quality=88/100  Signal level=-41 dBm
                    Extra: Last beacon: 190ms ago

Ještě doplním, že iwconfig ukazuje sílu signálu, kterou já přijímám od access pointu, zatímco iwlist eth1 scanning zobrazuje sílu signálu, kterou access point přijímá ode mě. Obě hodnoty jsou samozřejmě užitečné. Uf, to zas byla dlouhá zpráva...

[slim2]

Právě že se nenacházím v oblasti, která by byla nějak přehlcena wifi. Obsazené kanály jsem samozřejmě při konfiguraci hledal a našel jsem 1., 3. a 5. kanál obsazen. Tak jsem volil 9. Jinak teď jsem změnil kanál na 11., odstranil fragmentaci, vykon jsem zvyšil na 18dBm. Jen se mi nepodařilo na mém AP pohnout s hodnotou retry a sensitivitu jsem taky nezměnil. Síť taky nemám rozdělenou na dvě části, tak netuším co by mě to mohlo ještě rušit. Zase přikládám iwconfig:

ath0      IEEE 802.11g  ESSID:"xxxxxxxxxx"
          Mode:Master  Frequency:2.462 GHz  Access Point: 00:0B:6B:4D:8F:BB
          Bit Rate:0 kb/s   Tx-Power=18 dBm   Sensitivity=0/3
          Retry:off   RTS thr=300 B   Fragment thr:off
          Encryption key:xxxxxxxxxxxxx   Security mode:restricted
          Power Management:off
          Link Quality=27/94  Signal level=-68 dBm  Noise level=-95 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:2  Invalid misc:2   Missed beacon:0

[Andrej]

To už vypadá mnohem nadějněji - ukazuje se tam méně chyb. Pokud iwconfig neumožňuje nastavit retry, je několik možných příčin - nepodporuje to ovladač, hardware si to řeší sám a vůbec to nepodporuje nebo umí jen jednu variantu ze dvou možných, ne obě. (Těmi variantami myslím buď počet pokusů, nebo timeout.)

Ještě jsem zapomněl na další důležitou věc: hodnotu RST/CTS je potřeba nastavit i u klientů, jinak se to mine účinkem. (Jak už jsem ale psal, má smysl jen pokud na sebe dva nejvzdálenější (od sebe navzájem) klienti nevidí. Jinak zbytečně zpomaluje.)

Všichni klienti by měli mít napevno nastavenou MAC adresu Tvého AP. (Aby jim nikdo nemohl "podstrčit" jiný AP.) Taky by bylo dobré zkusit iwconfig ath0 rate auto. Tím se zajistí, že rychlost automaticky klesá při slabém provozu nebo při silném šumu. Naopak v případě potřeby se okamžitě zvedne, je-li to možné.

Napadá mě, že 1,3 MB/s odpovídá 802.11b. Ujisti se, že všechna zařízení v Tvé síti jsou opravdu přepnutá výhradně na g. Stačí jediné béčkové zařízení a celou síť to zpomalí k nepoznání, kvůli kompatibilitě.

Pokud jde o "Invalid nwid", to bývá opravdu způsobeno přítomností jiné sítě. Nebyl náhodou (omylem) zapnutý původní AP? Nebyl některý z klientů omylem v režimu master?

Pokud se ta rychlost nebude chtít dostat do normálu ani po přenastavení klientů i mastera, bude dobré se podívat do dokumentace k modulu pro Atheros. Tam se přesně dočteš, jaké registry zpřístupňuje příkaz iwpriv a co přesně jejich změna způsobí. Někdy se můžou opravdu hodit.

[slim2]

Jak se zdá, tak retry nedovoluje ovladač. Další špatná věc je u RTS/CST - 2 nejvzdálenější na sebe nevidí a tak to budu muset nějak zprovoznit. Jinak jsem se díval do nastavení u klientů a nevím jestli se náhodou u nich nenastavuje hodnota RTS v bitech, protože hodnotu jako 2347 u mě nenastavím. Proto jsem to podělil 8-mi a nastavil na mém atherosu 294B.

ath0      IEEE 802.11g  ESSID:"xxxxxxxxxxxxx"
          Mode:Master  Frequency:2.462 GHz  Access Point: 00:0B:6B:4D:8F:BB
          Bit Rate:0 kb/s   Tx-Power=18 dBm   Sensitivity=0/3
          Retry:off   RTS thr=294 B   Fragment thr:off
          Encryption key:xxxxxxxxxxxxxxx   Security mode:restricted
          Power Management:off
          Link Quality=27/94  Signal level=-68 dBm  Noise level=-95 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:199  Invalid misc:199   Missed beacon:0

A opět jsem přišel na to, že se karta asi zahltí a rychlost klesá zase k 80 - 90kBps. Tak tady přemýšlím, že to bude způsobeno asi Link Quality. Jinak tahle situace dříve nastávala asi po 5 minutách a nyní se to stalo asi po 15 hodinách.

[Andrej]

Ta hodnota RTS thr (někdy se tomu taky říká RTS treshold) není nic jiného než velikost paketu, při které se zapíná kontrola RTS/CTS. Manuálová stránka neříká nic o tom, jestli jsou to bity nebo byty. Spíš bych se ale přikláněl k těm bytům. Že některé zařízení neumí nastavovat liché délky apod., to je vcelku běžná věc.

Funguje to takhle: Když je paket menší než treshold, pošle se přímo, tj. "bez dovolení". Je tam potom jisté riziko, že se dostane do konfliktu s jinými pakety a že budou pak všechny poškozené a budou se muset poslat znova. Protože je ale paket krátký, předpokládá se, že takové výpadky jsou málo pravděpodobné. (Stojí za to riskovat a ušetřit overhead.)

U dlouhého paketu už takový přístup volit nelze. Proto jsou pakety větší než treshold přenášené "s dovolením", tj. napřed se pošle výzva a pak teprve (po obdržení odpovědi) samotný paket. Při tomto způsobu je zajištěno, že bude v té době kanál volný. Čím nižší je RTS treshold, tím častěji se používá RTS/CTS, tj. komunikace je lépe řízená, ale má mnohem větší overhead. Treshold lze nastavit i na nulu, což je ovšem dvojsečná zbraň, jako ostatně všechny extrémní hodnoty.

Z předchozího plyne: Není potřeba mít na klientech a na AP nastavené stejné hodnoty RTS treshold.

Připadá mi, jako by se buď u mastera nebo u některého z klientů nenastavovala automaticky rychlost. Všechny musí mít nastavené iwconfig ethX rate auto. Těch 80-90 kBps mi nápadně připomíná hodnotu 1 Mbps + overhead. Možná některý z klientů při nějakém chvilkovém šumu (zapnutí mikrovlnky, broušení, svařování atd...) snížil rychlost na 1 Mbps a pak už ji nezvýšil, když bylo potřeba. Je rychlost zhoršená mezi každými dvěma klienty?

[slim2]

Síť je v současné době taková, že je AP (Atheros) a celkem 3x AP Edimax EW-7209APg. Přes tyhle 3 Edimaxy je připojeno celkem 5 klientů. Na každém Edimaxu je nastaven mód 802.11b + 802.11g, takze si automaticky volí mód + rychlost je nastavena na auto. Na Atherosu mám nastaveno:

iwconfig ath0 rate 18M auto

Takže si myslím že preferuji rychlost 18Mbit a dále je tam nastaveno auto. I když jsem nechal nastavené pouze auto, tak se to nezměnilo.

Myslím, že je chyba asi v Madwifi, takže se chystám na kompilaci nových ovladačů. Protože tohle řeším již dva týdny a sice je teď znát trochu pokrok, ale není to stále v pořádku, takže mě napadá že chyba je jen v Madwifi.

[Andrej]

Volba 18 Mbit auto znamená, že maximální přípustná hodnota je 18 Mbit/s a při zarušeném prostředí by se měla automaticky snižovat a zvyšovat podle aktuální situace. (Nikdy ale nepřesáhne 18 Mbit/s.) U mnoha ovladačů má smysl koukat na rychlost jen při intenzivním přenosu dat. Například můj Asus M2N s chipsetem Intel Pro 2100 snižuje rychlost z 11 Mbit/s na 1 Mbit/s, jakmile není co přenášet. (Při přenosu ji zase ihned zvýší.) Aktuální rychlost se dá spolehlivě zjistit většinou jen přes iwpriv, pokud ten driver podporuje patřičné rozhraní. Jsou-li nové ovladače, rozhodně to stojí za zkoušku. Taky určitě prostuduj FAQ, většinou tam je bohatý seznam takových problémů a jejich řešení.

[slim2]

Ještě přemýšlím, jestli hodnota

Link Quality=28/94

nebude způsobena klientem s nejslabším signálem.

[Andrej]

Tak to přesně nevím. Je to ale dost dobře možné.

[opicak]

na těch 14 kanálů jsi byl kde? pokud vím tak se jich tam vleze leda 13. Takže tohle někomu říkat není až tak moc dobré.

[Andrej]

Kanálů je 14. Otázka je, které zařízení je podporuje. Kvůli zákonným omezením jich firmware určený pro Evropu umožňuje jen 13. Někde je povoleno dokonce jen 11 kanálů (v Japonsku, jestli se nemýlím). Pokud jich vidíš jen 13, máš zařízení s firmwarem podle evropských norem, což je běžné. Nevidím důvod, proč by se mělo tajit, že existuje víc kanálů, než kolik jich připouští zákonná norma. Ty snad ano? Na spoustě zařízení je univerzální firmware, který umožňuje nastavit oblast použití. Když si nastavíš stát s benevolentními normami, na čtrnáctku se dostaneš.

[Mk]

V Japonsku je práve těch 14, 11 je třeba v USA, proto některé notebooky (hlavně Acer) umí jen 11 kanálů. Nicméně za 13 kanálů můžeme být rádi, ve Francii až do nedávna bylo legálně možné používat jen kanály 10 - 13.

[Andrej]

No jo, máš pravdu... To jsem se nějak sekl.

[Zdeněk Štěpánek]

Hodnota Link Quality je u AP naprosto o nicem. Nainstaluj si wifimon, tam uvidis sili signalu od klientu. Pripadne WeWiMo je totez ale na webu.

RTS je v bytech a doporucuje se nastavit na 500. Je nutne ji nastavit na klientech, na APcku to nema prakticky zadny vliv. AP totiz vzdycky vi jestli je ve vzduchu klid nebo nekdo vysila. Kdezto klient nevi jestli jinej klient vysila.

Zdenek

[slim2]

Já se dívám na sílu signálu klientů přes

iwlist ath0 ap

Nevím, jestli je to tedy dobře, ale je tam síla signálu. U nejslabšího se pohybuje okolo -70dBm, takže by těch 11Mbit, mohlo bez problémů fungovat.

[Zdeněk Štěpánek]

Dulezity je nejen signal, ale i sum z toho vyplivajici SNR. Jedno bez druheho je k nicemu. pokud je rozdil apson 20 je to OK. Ja si uprimne hodnoty v dB moc nepamatuju, pouzivam radsi link quality neco/92, tak to hlasi 626ka i wifimon. Link quality od klienta by mel byt aspon 20.

Zdenek

[slim2]

Tak můj výpis:

iwlist ath0 ap
ath0      Peers/Access-Points in range:
    00:E0:00:9A:6A:72 : Quality=23/94  Signal level=-72 dBm  Noise level=-95 dBm
    00:E0:00:9A:6A:75 : Quality=27/94  Signal level=-68 dBm  Noise level=-95 dBm
    00:E0:00:9A:6A:70 : Quality=29/94  Signal level=-66 dBm  Noise level=-95 dBm

Takže všichni klienty mám přes 20, ale jak jsem již psal - myslím že problém je ve starých ovladačích Madwifi, takže bude nová kompilace jadra a pak se uvidí.

[slim2]

Dočasně jsem problém vyřešil tím, že jsem na AP nastavil mode 802.11b a rychlost fixně na 11Mbit. Síť takto funguje a prozatím je to dostačující.

[slim2]

Problém vyřešen. Po týdnu, kdy síť fungovala na rychlosti 11M fixně (rychlost odpovídala) jsem se rozhodl pro nové jadro. Konečné řešení tedy bylo kernel 2.6.16 a poslední verze madwifi. Nyní je již vše v pořádku.

[Rene]

Som stastny, ze som tuto diskusiu na webe objavil. Mam uplne rovnaky problem ako ten, co tu popisujete. Len malicka otazocka, mozem vediet aky kernel ste pouzivali predtym ako ste dosadili 2.6.16 ? Ja pouzivam 2.6.10 a neide to.

[slim2]

Hlavní problém nebyl ani tak v kernelu (2.6.15), jako ve staré verzi Madwifi (více jak rok). Ale když jsem kompiloval nové Madwifi, tak jsem zrovna měnil i kernel. Můžete napsat, co Vám přesně nejde?

[Rene]

Problem v mojom pripade je taky, ze pokial pouzijem smer -> smer tak je vsetko vporiadku, ide to aj na starsich driveroch a aj s kernelom 2.4 Potrebujem vsak rozchodit smer -> vsesmer a tam nastava problem. Pouzil som aj najnovsi driver (z 2.5.2006) aj kernel 2.6.16. Stale robi ten isty problem a to: klient sa pripoji na vsesmer bez problemov, bitrate ukazuje 36 Mbit. Pokial cez spoj nic neprenasam je to v pohode, staci ale len ping xxx.xxx.xxx.xxx -s 40000 , zacne to bez problemov ale behom takych 10 sekund mam bitrate 6 Mbit ! A ja nechapem preco, vysielaci kanal je 100 , na vsesmeri je wrap a mini pci atheros karta, u klienta je klasicke pc a pouzita je pci to mini pci redukcia a atheros mini pci karta. Prosim Vas neviete v com by mohol byt problem ? Uz som vyskusal snad skoro vsetko ... Dakujem za odpoved.

[vencour]

Máme na jendom místě všesměr AP, běží pčes wep, já mam teď kernel 2.6.16.13 a verzi madwifi madwifi-ng-r1529-20060426 a běhalo mi to ok.

[Rene]

1. Mozem vediet aku ste dosiahli realnu prenosovu kapacitu ? Mne sa to teraz chova tak, ze klient ukazuje cez iwconfig bitrate 36Mbit/s, ale iperf ukazuje realnu prenosovu rychlost okolo tych 3 - 4 Mbit ... Cize akurat som dosiahol to, ze uz klient nevypisuje stratu, resp. pokles bitrate, ale co sa tyka prenosovej rychlosti, je to daleko od tej aka by mala byt, teda mala by byt aspon tych 10Mbit/s urcite, ale nie je ... 2. Mate aktivovany iwpriv ath0 doth 1 ? Resp. mate nastaveny txpower na nejaku fixnu hodnotu ? Aky prenosovy kanal pouzivate ?

[vencour]

V testech mi to ukazuje: na www.rychlost.cz

stahování:897.856 kbps (112.232 kB/s)
upload:909.264 kbps (113.658 kB/s)
web odezva:min:37.6ms průměr:42.1ms max:44.6ms

a na www.dsl.cz

Rychlost připojení k internetu:	932,84 kbit/s
Rychlost stahování dat:	116,6 kByte/s
Rychlost odezvy (ping):	min 22,283 ms
max 36,494 ms
Ø 25,969 ms

Pokud jde o iwpriv ath0 dot, tak nastavení ath0

# iwpriv ath0 -a
ath0      Available read-only private ioctl :
ath0      getoptie:
ath0      getchanlist:
ath0      getchaninfo:
ath0      get_mode:11g
ath0      get_authmode:1
ath0      get_protmode:1
ath0      get_mcastcipher:1
ath0      get_mcastkeylen:16
ath0      get_uciphers:15
ath0      get_ucastcipher:0
ath0      get_ucastkeylen:13
ath0      get_keymgtalgs:3
ath0      get_rsncaps:0
ath0      get_hostroaming:1
ath0      get_privacy:1
ath0      get_countermeas:0
ath0      get_dropunencry:0
ath0      get_wpa:0
ath0      get_driver_caps:2005065743
ath0      get_wmm:1
ath0      get_hide_ssid:0
ath0      get_ap_bridge:1
ath0      get_inact:300
ath0      get_inact_auth:180
ath0      get_inact_init:30
ath0      get_abolt:218
ath0      get_dtim_period:0
ath0      get_bintval:100
ath0      get_doth:1
ath0      get_doth_pwrtgt:18
ath0      get_compression:0
ath0      get_ff:1
ath0      get_turbo:1
ath0      get_xr:1
ath0      get_burst:1
ath0      get_pureg:0
ath0      get_ar:1
ath0      get_wds:0
ath0      get_bgscan:1
ath0      get_bgscanidle:252
ath0      get_bgscanintvl:300
ath0      get_mcast_rate:1000
ath0      get_coveragecls:0
ath0      get_countryie:0
ath0      get_scanvalid:60
ath0      get_regclass:0
ath0      get_rssi11a:24
ath0      get_rssi11b:24
ath0      get_rssi11g:24
ath0      get_rate11a:48
ath0      get_rate11b:10
ath0      get_rate11g:18
ath0      get_uapsd:0
ath0      get_sleep:0
ath0      get_eospdrop:0
ath0      get_markdfs:1

V Mandrivě jsem nechal konfiguraci na auto, zadal SSID a wep klíč a rozjelo se mi to. Čili jsem s wifi spokojený.

[Rene]

Noo takto, ja som skor potreboval vediet ohladom tej rychlosti ani nie tak rychlost do internetu, ale rychlost medzi klientom a vsesmerom, teda max. rychlost, ktoru dokazu medzi sebou preniest, v linuxe sa to da testnut jednoducho pomocou iperf. Na strane vsesmeru spustite iperf -s. No a na strane klienta iperf -c xxx.xxx.xxx.xxx To xxx samozrejme predstavuje ip, ktora je nastavena na tom vsesmeri. Tento vysledok by som skor potreboval vediet, ak to je mozne. Dakujem za vypis z iwpriv, mrknem na to ci je to tak nastavene aj u mna.

[vencour]

iperf u sebe nevedu, na iw mam

iwconfig  iwevent   iwgetid   iwlist    iwpriv    iwspy

a na ip mam

ip                ipcs              ipset             iptables-save
ipcalc            iplog             iptables          iptunnel
ipcrm             ipmaddr           iptables-restore  ipv6calc

Tak jsem ho na rpmSeek našel, ale ...

# iperf -c 10.1.21.10
connect failed: Connection refused

Máme tu totiž hw apéčko. Čím ještě mohu pomoci, sire?

[Rene]

Hmm, prave som zistil, ze som pouzival stare binarky od tools pre madwifi a novy driver (ng z 10.5.2006) a vtedy mi klient neukazoval pokles bitrate, ale ked som teraz pouzil spravne binarky k verzii ng z 10.5.2006 tak opat mam tu pokles bitrate ;) Jadro mam 2.6.10, verzia madwifi je http://snapshots.madwifi.org/madwifi-ng/madwifi-ng-r1545-20060510.tar.gz Mate este nejake napady kde by mohol byt problem ? Vsimol som si,ze od 1.5.2006 je verzia madwifi len 2 MB, pricom este koncom aprila mala verzia madwifi 3 MB, neviete co sa stalo, preco o ten 1 MB isla dole ?

[vencour]

Myslíte, že znáte teorii aspoň trochu? Nenajdete zde v tomto souhrnu něco nového? Tj. nemáte nějak zarušené prostředí? Já mam pocit, že rychlost na fyzické vrstvě je nejvyšší možná, když není, tak má k tomu důvod.

Madwifi drajvry jsem stahoval asi 29.4., čili novější nemám a obešel jsem se zatim bez nich.

[Rene]

No zaoberam sa wifi uz nejaky ten rocik, zarusene to nie, urobil som scan ... Vy to skusate v mode 802.11g, ja to mam zasa v 802.11a , ja som sa vlastne do tejto diskusie pripojil len preto, ze som tu zbadal presne ten isty problem ako mam ja, mne to totiz v 802.11b bezi bez problemov, problem je len v mode 802.11a a to som uz vyskusal 2 typy 5Ghz vsesmerov ... nic to budem skusat nieco dalej, dik za pomoc a nech to slape ako ma :)