Byla vydána nová verze 9.9p2 sady aplikací pro SSH komunikaci OpenSSH. Řešeny jsou 2 bezpečnostní chyby: CVE-2025-26465 (MITM pokud je zapnuta volba VerifyHostKeyDNS, ve výchozím stavu je vypnuta) a CVE-2025-26466 (DoS). Detaily na stránkách společnosti Qualys (txt).
Argentinský prezident Javier Milei čelí více než stovce žalob a trestních oznámení kvůli spáchání podvodu, protože na svých sociálních sítích propagoval kryptoměnu $LIBRA, jejíž hodnota se v krátké době znásobila a pak zhroutila.
Wayland Protocols byly vydány ve verzi 1.41. S dlouho očekávaným protokolem správy barev a High Dynamic Range (HDR).
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.11.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest (Wikipedie) v říjnu loňského roku přejmenovaný na Luanti.
V stredu 19. 02. 2025 o 10:00h bude spustený jarný webinár zdarma. Na tomto webinári si ukážeme praktické ukážky monitorovania Prometheus endpointov s využitím nástroja Zabbix. Účastníci sa dozvedia, ako nastaviť a konfigurovať Zabbix na zber dát z prometheus exporterov vrátane vytvárania LLD pravidiel. Tento webinár je určený pre mierne pokročilých administrátorov Zabbixu. Registrácia na stránke: Axians Slovakia. Zoznam všetkých webinárov: Axians Slovakia webináre.
Byla vydána beta verze GNOME 48. Vyzkoušet lze instalační ISO GNOME OS. Vydání GNOME 48 je plánováno na březen.
Bochs (Wikipedie), tj. emulátor počítačů typu x86 a x86-64, byl vydán ve verzi 3.0.
Věříte své kalkulačce? Kolik je (10^100) + 1 − (10^100)? A kolik 1%−1%?
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
FlappyFavi, hra Flappy Bird v ikoně Favicon. Nefunguje na mobilech.
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.
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í...
iwconfig ath0 rts 300 iwconfig ath0 frag 300Již dříve jsem měl:
iwconfig ath0 power offRozdí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
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...
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
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.
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:0A 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.
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?
iwconfig ath0 rate 18M autoTakž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.
Link Quality=28/94nebude způsobena klientem s nejslabším signálem.
iwlist ath0 apNeví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.
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 dBmTakž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í.
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.
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.6msa 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 msPokud 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:1V Mandrivě jsem nechal konfiguraci na auto, zadal SSID a wep klíč a rozjelo se mi to. Čili jsem s wifi spokojený.
iperf
u sebe nevedu, na iw mam
iwconfig iwevent iwgetid iwlist iwpriv iwspya na ip mam
ip ipcs ipset iptables-save ipcalc iplog iptables iptunnel ipcrm ipmaddr iptables-restore ipv6calcTak jsem ho na rpmSeek našel, ale ...
# iperf -c 10.1.21.10 connect failed: Connection refusedMáme tu totiž hw apéčko. Čím ještě mohu pomoci, sire?
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.
Tiskni
Sdílej: