Misztikus hiba a kimenő forgalomban

Hálózatok általános

Kedves HUP-osok!

Egy misztikus hibába futottam bele, azt se tudom, merre induljak. (Google nem segített.)

Vettem itthonra egy új desktop gépet, amire felhúztam egy friss Ubuntut. Először minden rendben valónak tűnt: települt a rendszer, sok száz MB-nyi telepítő cuccot húzott le a netről, amíg feltettem az általam igényelt csomagokat.

Böngészni simán tudok, illetve néha egy-egy weboldal nem jön be időtúllépéses hibát jelezve, de aztán mégiscsak bejönnek azok a lapok is.

Ssh-zni már nem tudok róla. Se levelet küldeni. Itt is mindig időtúllépéses hibát kapok. Pontosabban: pár soros, egy címzettes tesztlevelek átmennek, kicsit hosszabbak nem.

Sok mindenre gondoltam, kínomban egy másik wifi cuccot is beletettem, de azzal is ugyanezt kapom. (Nem akartam drótot huzigálni, wifi kártyát tettem bele alapból, de a külön, ideiglenesen rádugott USB-s wifivel is ugyanaz a viselkedés.)

Eközben ugyanarról a routerról a laptopom vígan netezik.

Merre induljak? Ha kell, megadok minden adatot, csak nem tudom, mi releváns.

Előre is kösz a segítséget!

  • 7235 megtekintés

( n.balazs v | 2012. 06. 20., sze – 07:17 )

MTU mekkorára van beállítva?

+1, nálam is ez a probléma a sis chipsetes asus laptopnál. Semmilyen Linux nem megy a gyári 1500 mtu-val, 1492 vel már viszont jó. A hiba amiket a kérdező ír elég tipikusak, rossz mtunál van ami megy van ami nem. A pontos okát nem tudom, csak hogy az ifconfig eth0 mtu 1492 segít.

( Szenti v | 2012. 06. 20., sze – 09:28 )

Mivel otthoni routerről van szó, meg kell kérdeznem: újraindítottad-e a routert? Volt tapasztalatom olyan routerrel, aminek a torrentezés miatt úgy megtelt a memóriája, hogy utána az admin felülete sem volt elérhető HTTP-n keresztül. A reboot segített rajta.

Még egy pár kérdés:
* ubuntu-s gépről ping-re jön-e válasz? --> index.hu -t, vagy ha nincs névfeloldás, akkor 217.20.130.97. Vagy egyáltalán a routertől? Vagy a laptopotól?
* A Wi-Fi hálózatod melyik 802.11 szabvány szerint üzemel? Nekem van olyan tapasztalatom, hogy "N"-es laptop eldobálja a netet, ha a router "N"-es. A routert "G" módra állítva a probléma megszűnt.

( athila v | 2012. 06. 20., sze – 09:57 )

Ha valamilyen PPPoE-s internethozzáférésed van, akkor állíts az Ubuntun 1492 byte-os MTU-t.

a kernel, ami pont elég;)
Kérdés az, hogy milyen internet hozzáférésed van (mert e szerint kéne belőni az mtu-t).
A hibajelenségek alapján ez lesz a probléma, csupán azt nem értem hogy ha nagyobb az mtu, miért nem fragmentálódnak a csomagok rendesen.
Win7 64-biten van ilyen probléma ami a TCP/IP stacket érinti fragmentálás szempontból, nem tudtam hogy ezt a feature-t átvette a linux is;)

( uid_18247 | 2012. 06. 20., sze – 12:12 )

próbálj ki valami gyökeresen más disztrót (pl. SystemrescueCD, hogy ne kelljen installálni), és azon is játssz a MTU-val.

a routerre milyen más eszközök csatlakoznak, milyen MTU-t használnak, és jellemzően mit tesznek? lehet, hogy a QoS van úgy elállítva, hogy másik eszközt/eszközöket preferál bizonyos típusú traffic esetében.

nem hiszem, hogy NAT probléma lenne (esetleg valami gebasz a portok kiosztásával/tiltásával stb), de a biztonság kedvéért írd, ha van rajtuk valami szokatlan beállítás.

( Cybernet | 2012. 06. 20., sze – 13:32 )

Érdekel a megoldás. Ha megvan, írd le légyszi.
Ha megint az Ubuntu 12 a hunyó, akkor MEGINT csak gratulálni tudok nekik, hogy milyen iramban mennek a süllyesztőbe...

( horvatha | 2012. 06. 20., sze – 17:47 )

A válasz nagyjából megvan, de nem vagyok nyugodt.

Tehát: 1500 volt az MTU, de ugyanennyi volt a laptopomon is, ami tökéletesen működött.

Levettem 1492-re (sok helyütt ajánlott érték), majd 1480-ra, ..., de végül 1280-on kötöttem ki, amivel úgy tűnik, rendesen megy.

Még nem régóta használom, de most tudtam nagy levelet küldeni, rsync-elni, ssh-zni, stb.

Viszont marhára nem értem, hogy a laptop miért megy el 1500-as MTU-val, ez meg miért nem. Nyugodjak meg, vagy még jöhet valami meglepetés?

A Mixed ez esetben nem gond, mivel a routered max G-s (54 Mbps) sebességre képes max.
Ez a szabvány stabilabb, mint az "N"-es, ahol sok gyártó még a szabvány kijövetle előtt kiadta a saját eszközeit. Ezek a pre-N-es cuccok tudnak galibát okozni.

Most, hogy tudjuk azt is, hogy kábelnet, bátran javasolhatom azt, hogy a routereden vedd lejjebb az MTU-t (miközben a problémás gépen visszaállítod az alapértelmezett MTU értéket). MTU értéknek először próbálj meg 1500-at, majd 1492-t adni a routeren (utána a biztonság kedvéért rebootold a routert).

Ezek elvben meg kell oldják a problémádat. Ha mégsem, akkorl a vl és PunishR kolléga által javasolt ping + tcpdump kombót is megpróbálnám olyankor, amikor éppen "nem működik" a net az Ubuntus gépről.

Ha a routeren lejjeb veszem az MTU-t, akkor az nem zavarja meg az eddig sikerrel csatlakozó gépeket?

További fejlemény: a kisebb (1280)-as MTU-val is akadozott néha, úgy minden 5. weblap várt-várt és egy reload oldotta meg a helyzetet, de rsync-elés (ssh-val) feltöltés irányba nem ment. Kínomban 512-re vettem az MTU-t, most megy (eddig) minden, de továbbra is ideges vagyok.

(Egyébként a kis MTU sokkal gyorsabb reakcióidőket eredményezett pl. webböngészéskor.)

Viszont marhára nem értem, hogy a laptop miért megy el 1500-as MTU-val, ez meg miért nem. Nyugodjak meg, vagy még jöhet valami meglepetés?

Ha ki akarod deríteni, vedd elő mindkét gépet, nyomj egy
ping -s 1472 "random, ping-re válaszoló ip cím"
parancsot rajtuk, és nézd meg tcpdumppal, hogy mi történik.

( pepelopez | 2012. 06. 21., cs – 07:04 )

szerintem wifi driver probléma nekem a b43 időnként megborul wheeze alatt pl.

( zui84 | 2012. 06. 21., cs – 16:05 )

Hello,

Esetleg?

cat /proc/sys/net/ipv4/ip_no_pmtu_disc

"The ip_no_pmtu_disc disables PMTU (Path Maximum Transfer Unit) discovery if enabled. In most cases this is good, so it is per default set to FALSE (ie, Path Maximum Transfer Unit is used). However, in some cases this is bad and may lead to broken connectivity. If you are experiencing problems like this, you should turn this option off and set your MTU to a reasonable value yourself.

Do note that MTU and PMTU are two different things. MTU tells the kernel the maximum transfer unit for our connection, but not over the whole connection to the other end. PMTU discovery tries to discover the maximum transfer unit to specific hosts, including all the intermediate hops on the way there.

The default value is that the ip_no_pmtu_disc is FALSE, as already stated. If this is set to TRUE, PMTU discovery is turned off. The ip_no_pmtu_disc takes a boolean value, in other words either an 1 or a 0, where 1 is on and 0 is off."

forras: http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/variablereference…

( athila v | 2012. 06. 23., szo – 14:47 )

Hagyd ki a routert és közvetlenül a modembe csatlakoztasd a géped, állítsd 1500 byte-ra az MTU-t és így kizárod a PC/OS hibát.