Dotaz: Internet se začne "zadrhávat" po náhodné době cca 24 hodin od spuštění počítače

[xsouku04]

Mám aktuální archlinux. Pokud nechám počítač puštěný přes noc, je pravděpodobné, že se následujíci den začne internet zadrhávat a je to nepoužitelné. Pingání jde a nějaké malé náhodné stránky se možná hlemýždím tempem podaří načíst. Skype pořád svítí online, ale jinak je to nepoužitelné.

Router mám TP-LINK TL-R860. Restart routeru ani cisco switche nepomůže. Bez problému jej používám už několik let.

Co jsem už zkusil. Mám dvě síťové karty. Jednu integrovanou a jednu přidávnou v PCI.

lspci|grep Ethernet

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B 
PCI Express Gigabit Ethernet controller (rev 06)

hwdetect --show-net
NET    : r8169 8139cp 8139too mii ppp_generic slhc

Problém existuje s oběma síťovkami naprosto identicky. Tedy zkoušel jsem počítač připojit pomocí jedné i druhé síťovky a problém je identický. Také jsem zkoušel alternativní ovladač na jak popsáno zde To je právě ten právě používaný r8169.

Nepomůže /etc/rc.d/network restart dokonce ani

/etc/rc.d/network stop
modprobe -r r8169
modprobe r8169
/etc/rc.d/network start

Nepomůže ani zabít dhcpcd a znovu spustit. Ip adresu dostanu, do lokální sítě se dostanu, ale internet zlobí.

Nedávno měl můj poskytovatel internetu s problém s doustupností některých serverů (např. root.cz, wiki.4smart.cz) když bylo MTU nastaveno na 1500. Je to již opravané ale nyní stejně pro jistotu nastavuje jím doporučenou hodnotu mtu v /etc/rc.local

ip link set eth1 mtu 1472
ip link set eth0 mtu 1472

Nepomůže ani nastavit MTU nějakou nižší hodnotu.

Podezřívám, že za to může můj poskytovatel internetu NETBOX. Netbox jinak není žádný troškař, ale asi největší poskytovatel netu v Brně. Bohužel do paneláku kde bydlím nemají optiku ale táhnou to vzduchem (myslím že to bude nějaké liconcované pásmo), ale jinak je internet kvalitní. Absolutně ale nechápu v čem by to přesně mohlo spočívat. VoIP telefony fungují dlohodobě bez potíží.

Zatím mi tedy nezbývá nic jiného než každý večer počítač vypínat. Nemohu použít s2ram, který jinak funguje bez potíží. To mohu použít jen pokud jdu během dne někam pryč. Stane se to ale i když počítač běží celou noc, takže suspend nemůže být příčina. Bohužel většina lidí počítač vypíná, takže tohle neřeší :) Mohl bych nechat schválně asi zapnutý jiný počítač, jestli se to stane taky, projevení se problémů může ale náhodně trvat i několik dní.

Nesetkal jste se někdo s podobnou záhadou? Co pomohlo? Co mohu ještě zkusit? U běžného stolního počítače se s tím dá ještě žít, pokud by to ale dělal třeba server nebo ústředna, tak je to fakt špatný :)

Odpovědi

[Dr. Eddy]

Zkousel jsi vecer vypnout sit (/etc/rc.d/network stop) zapnout ji az rano? Kdyztak jeste modprobe -r na ovladac ty sitovky.

Jde o to, aby se z pohledu site tvaril pocitac jako vypnuty. Takze mozna jeste vytahnout kabel...

Tim zjistis, jestli je problem u tebe nebo v siti...

[xsouku04]

Nyní jsem začal dělat to, že na noc vypínám router, switch a počítač uspím pomocí s2ram. Zatím se to ještě nestalo (jedna noc a půl dne), ale jásat je předčasné. Jestli to pomůže, tak uvažuji

Asi vyměním router za nějakem miniaturní nízkospotřebovej linux a switch koupím atcom (použiji to hlavně jako router a přístup do domácí sítě - stejně to potřebuji odzkoušet kvůli ústředně) No a jako switch zase něco jako tohle. Umí to vlany a měl bych pak mít přehled o tom kam který drát vede. Těm klikacím routerům bez linuxu nevěřím. Dobře by měli jít pak snadno zkoumat různé záludnosti. Jen tedy doufám, že nebude také odpojovat sám od sebe.

netgear JFS524E Je to drahý ale už jsem z toho chaosu pod stolem unavenej.

Nebo víte někdo o nějaké lepší kombinaci ?

[xsouku04]

Tak jsem to zkoušel dvě noci vypínat switch s routerem a zaseklo se to dneska během dne.

Už ale vím, že potíže jsou jen s TCP, UDP funguje dále bez potíží.

[lertimir]

Nejdříve bych zkusil odsledovat co se na síti děje pomocí wiresharku. Tedy jestli špatně a pomalu odpovídá DNS nebo jsou jinde problémy, je vidět něm v jakých časech je paket odeslán a kdy se vrací odpověď.

[xsouku04]

Aha to není špatný nápad. Podle mého názoru uvidím hlavně to, že se mi pakety nějak nevrací. DNS mohu vyloučit, protože ping funguje i resolvuje dobře. Drhne to prostě až při stahování.

[lertimir]

A jak fungují jiné protokoly nad TCP, jako ftp, sftp, smtp. Je TCP spolehlivé? Chodí správně potvrzovací pakety? V tom záchytu jsou zdržení na timeout paketů nebo proč?

[xsouku04]

Nic na TCP nechodí dobře a udp jsem nezkoušel, ale pravda mohl bych. Třeba VoIP komunikuje výhradně na udp. Takže můžu zkusit třeba volat z twinkle. Taky zkusím volat ze skypu, jestli to půjde.Skype také pokud je to možné určitě posílá hovory přes udp.

Příznaky jsou podobné jako při problému s MTU, který je tam detailně popsán. Rozdíl je zdá se hlavně v tom, že nejdou dobře vůbec žádné stránky, ani se nepřihlásím přes ssh.

[lertimir]

Při pečlivém procházení záchytu wiresharku by se mělo najit co se děje. Jestli u TCP projde vždy otvirací trojcestný handshaking? jestli běhají spravně Acknowledge packety? Jestli pakety přijdou na IP úrovni fragmentované? Jestli dojde správně paketů k odeslané velikosti okna? Které pakety chybí?

MTU tedy (maximal transmission unit) je specifikace maximální velikosti paketu na daném rozhraní (lince). Pro Ethernet je MTU 1500 bytů. Různé technologie mají různou MTU. Např. ADSL používá pro přenos na lince protokol PPP over Ethernet (PPPoE), který do Ethernetového frame ještě vloží PPP hlavičku a pak teprve data, čímž sníží velikost použitelných uživatelských o 8 dat na 1492. Pokud od stanice přijde routeru frame s 1500 daty, musí jej router na ADSL linku nafragmentovat na dva fragmenty na IP úrovni. Nastavím-li si na Ethernetové rozhraní MTU 1492, vím že se mi pakety nebudou fragmentovat na routeru. TCP to udělá autovaticky správně a UDP se mi pro velké pakety nafragmentuje již na stanici. Pokud nechám 1500 a router to dělá špatně může být problem. Ale v tom záchytu by mělo být i vidět jaké maximální MTU prošly i případně ICMP pakety se zprávami, že něco nešlo fragmentovat.

[xsouku04]

Díky za vysvětlení. Lze z toho udělat tedy závěr, že kdo je připojený přes ADSL nebo VDSL tak je pro něj vždy lepší nastavit MTU na 1492 ?

Problém mého problému je, že se vyskytne jen jednou za několik dní náhodně když se to nehodí a chystám dělat něco jiného než honit pakety po lokální síti :)

[lertimir]

Já jsem to nemyslel honit to nějak silně. Ale prostě v té chvíli kdy to nechodí, tak spustit wireshark a dívat se, co se tedy na síti děje.

Já nastavení MTU na 1492 pro ADSL používám, nicméně když je router v pořádku, tak to v pohodě rozdělí a v podstatě se hlavně jedná o některé UDP pakety, protože praxe by na TCP měla být taková, že se obě strany dokážou dohodnout na takové MTU, která projde celou cestu bez fragmentace.

[Trubicoid2]

Mne rtl8111 divne usinal, vzdy v noci, kdyz nebyl provoz, ale ne kazdy den. Zhruba jednou za tyden, posilal jsem to i do bugzilly, ale nic.

Je to kvuli runtime pm, na karte ho zmen z auto na on. Ja to mam v /sys/device/pci0000:00/0000:00:0a0/0000:02:00.0/power/control

[Jashin©]

Zkusil bych si vypsat všechna spojení - netstat

Něco ti může otvírat mraky spojení a pak to zahltí i ty kapesní routery.

[lertimir]

Tohle by tazateli vyřešil restart routeru. A ten mu nepomůže.

[Jashin©]

Některé spojení vyhnívají i za několik hodin.