Timeouty a 85% packets loss na síťovém rozhraní mého Linux PC

[fotka]

Ahoj,

chtěl bych poprosit o pomoc, pokud se vyznáte v síťové komunikaci, timeoutech,

zkoušel jsem ping na dva různé vzdálené proxy servery (různé země) ke kterým mám aktivní spojení, ale "journalctl" na mém PC mi neustále zaplavují zprávy ohledně těchto spojení:

Kód: [Vybrat]

ss-qt5[*]: TCP connection timeout.A spojení je skutečně nestabilní (soudě podle načítání internetových stránek, které často končí timeoutem).

Na síťovém rozhraní mého PC (Linux Arch) při pokusu o pingy na ten vzdálený server (Linux CentOS, jiná země) pomocí mtr (mtr -u remoteip -P remoteport) se zobrazuje (viz. obrázek) ztráta paketů na síťovém rozhraní mého PC odkud mtr spouštím. Je to první interface/IP které se v řetězu zobrazuje a je to IP adresa rozhraní Wireguard tunelu. Ale následující uzly (či jak se tomu říká) v tom řetězu směrem k cíli už stejnou ztrátu paketu neukazují. Běželo to paralelně asi 10 minut, výsledky pingů:
  udp - 88%(10.66.66.1)......0%......30%(hop 9, *.your-cloud.host)...0%(cíl)
   tcp - 98%(10.66.66.1)......0%......96%(hop 9, *.your-cloud.host)....0%(cíl)
icmp - 10%(10.66.66.1)......0%......57%(hop 9, *.your-cloud.host)....0%(cíl)
podobná ztráta na lokálním rozhraní je vidět i v případě pingů na druhý můj server ale ping jde jinou cestou a po cestě už není žádný bod který by měl ztrátu větší než 6%(předposlední bod). V případě icmp jsou ztráty výrazně nižší, i na lokálním rozhraní(pouze 20%).



ifconfig na serveru ukazuje pouze 11735 dropped packets za dlouhou dobu. journalctl má za 36 hodin asi 3 miliony zmíněných TCP timeoutů. Také se zobrazují chyby "AEAD data chunk is incomplete (too small for payload)"

Můj PC má docela vysokou síťovou aktivitu, možná je potřeba upravit nějaké Linux parametry, jen nevím jaké příkazy použít abych zjistil které síťové limity mohou být vyčerpány? Děkuji předem za příp. zpětnou vazbu

[Reklama]

[IDontCare]

Serfujes sifrovane pres proxy, ktera je ocividne dost vytizena. Tvoje pripojeni je uplne v pohode.

Bud proxy nepouzivej, nebo si najdi nejaky pouzitelny server.

[fotka]

Ne, nemyslím si. Takovéto rady jsou úsměvné - nefunguje ti to? kup si nový počítač. Oba servery jsou po stránce CPU i sítě naddimenzovaný. Jak už jsem psal, spíše bych to viděl na software limity. Například na klientu (domácí PC) vidím jako výstup "dstat --socket" že hodnota total sockets je těsně pod 1000 nebo je 1000. Mám podezření jestli toto není nějaký softwarový limit. "ulimit -a" ukazuje "open files                      (-n) 1024". Ale ani po navýšení "ulimit -n 30000" z root terminálu se ty TCP timeouty neztratí.
díval jsem se počet otevřených síťových socketů té proxy aplikace a na obou (klient/server) je to pod 50. Říkám si, jestli ty timeouty neznamenají že můj internetový prohlížeč používající tu proxy nekontaktuje nějakou nedostupnou www stránku (třeba nějaké rozšíření prohlížeče).

Jinak by mě ale stále zajímalo to jak zkontrolovat ty softwarové limity co se týče sítě, kdyby byl někdo ochotný tak děkuji předem.

[Mlocik97]

"Ne, nemyslím si." Takové odpovede ľudí, ktorým niečo nejde, sú bežné, a pri tom v 90% je problém tam, kde si myslia že není.

[FKoudelka]

Ne, nemyslím si. Takovéto rady jsou úsměvné - nefunguje ti to? kup si nový počítač. Oba servery jsou po stránce CPU i sítě naddimenzovaný. Jak už jsem psal, spíše bych to viděl na software limity. Například na klientu (domácí PC) vidím jako výstup "dstat --socket" že hodnota total sockets je těsně pod 1000 nebo je 1000. Mám podezření jestli toto není nějaký softwarový limit. "ulimit -a" ukazuje "open files                      (-n) 1024". Ale ani po navýšení "ulimit -n 30000" z root terminálu se ty TCP timeouty neztratí.
díval jsem se počet otevřených síťových socketů té proxy aplikace a na obou (klient/server) je to pod 50. Říkám si, jestli ty timeouty neznamenají že můj internetový prohlížeč používající tu proxy nekontaktuje nějakou nedostupnou www stránku (třeba nějaké rozšíření prohlížeče).

Jinak by mě ale stále zajímalo to jak zkontrolovat ty softwarové limity co se týče sítě, kdyby byl někdo ochotný tak děkuji předem.

Ne, nemyslím si , že bys měl napsat někomu, kdo se snaží ti poradit, že je  úsměvný.  IDontCare asi nemyslel tvé servery , ale proxy server který používáš, jakkoli si nejsem jist, zda na to kápl. R
Zrovna tak si nemyslím, že by počet otevřených souborů “-n” měl něco společného s rychlostí sítě.
Možná bych zkusil velikost MTU, fragmenataci apod, ale nechci radit úsměvně, takže doporučuji google.

[Reklama]

[Miroslav Šilhavý]

Mně se děly podobné věci na jedné síťovce, která měla TCP checksum offloading a nerozuměla si selektivně s některými jinými prvky. Nezkoumal jsem to moc do hloubky, prostě jsem vypnul tcp checksum offloading, ale byla to dost hnusná duchařina na to přijít. Protože např. ICMP a UDP fungovaly skvěle, jen TCP a ještě jen vůči některým zařízením měl ztráty.

Neříkám tím, že je to příčina zmiňovaného problému, jen chci nasměrovat k tomu, že hardware síťovky dnes zasahuje i do L4.

[johanson14]

Ten prvý Hop, to je nejaké rádio?

[fotka]

Mně se děly podobné věci na jedné síťovce, která měla TCP checksum offloading

děkuji, na klientu:

$ ethtool -k wg0
Features for wg0:
rx-checksumming: on
tx-checksumming: on

na hlavním interface také zapnuto..

Na serveru:
rx-checksumming: on [fixed]
tx-checksumming: on

Zkusil jsem tedy vypnout na obou rozhraních klienta i serveru: ethtool -K eth0 rx off tx off
na serveru se vypnul jen tx checksumming ale ne rx: "Cannot change rx-checksumming"
vypnout/zapnout síť na klientu a na serveru "service network reload"
vypnout/zapnout proxy aplikaci
no a pak jsem tedy sledoval zda dojde k těm TCP timeoutům a zkoušel tcp,udp,icmp pingy. Výsledek se zdá být stejný jako předtím. Počítám, že mám ten checksumming znovu zapnout?

Ten prvý Hop, to je nejaké rádio?

První adresa ve výpisu je síť. rozhraní wireguardu tunelu na počítači z kterého ping je odesílán. Další je wireguard server, který to přeposílá dál kam je potřeba, v tomto případě na socks proxy server který kontaktuje ta proxy aplikace.

[fotka]

Tak zatím příčina a příkazy vedoucí k jejímu zjištění neznámé.
"dstat --socket" ukazuje 2k socekts, z toho asi 700tcp a 13 udp

[Martin Oles]

Jak vypadá výstup z  netstat -ni"?
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500  1375870      0      0 0        620386      0      0      0 BMRU

RX ERR = problém na fyzické vrstvě
RX OVR = síťovku nestíhá odbavovat CPU

Dále pak se podívejte na výstup z "ethtool -S ethX" (sem dejte správný interface), zda tam není hodnota, která se značně zvětšuje. Namátkou "rx_missed_errors", "rx_overflow_errors" a podobně.

[fotka]

netstat -ni

netstat jsem neměl nainstalovaný, místo toho se používá "ss", tak jsem nainstaloval net-tools a výstup netstatu je:

Kód: [Vybrat]

Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
enp3s0    1500 230631668      0   1973 0      508857109      0      0      0 BMRU
lo       65536  2725077      0      0 0       2725077      0      0      0 LRU
wg0       1420 230548108      0      0 0      508771146      0   4216      0 OPRU

tedy rx-err a rx-ovr je 0
U serveru který má uptime asi rok jsou také nulové.

mtr (ping) už nezobrazuje výraznější ztrátu packetů a www stránky se už načítají docela dobře.

Možná že pomohl nějaký příkaz ohledně změn parametrů kernelu ohledně sítě (dstat --socket zobrazoval 1k sockets a nyní 2k), nemůžu na klientu najít sysctl.conf ani jiný soubor upravující kernel parametry sítě (locate sysctl.conf;ls /etc|grep sysctl), ulimit -a nezobazuje žádnou hodnotu blízko 2000). Hledal jsem nějaký skript, který by zobrazil využití síťových limitů kernelu (sysctl) ale nenašel.

ethtool -S ethX

Ohledně ethtool příkazu jsem na klientu zjistil nulové hodnoty errors, missed, collisions, aborted
Na serveru "no stats available", zkoušel jsem všechna rozhraní.

⚠️
Přesto za poslední minutu jsem napočítal 798 zpráv "ss-qt5[1006]: TCP connection timeout." v journalctl...
ve /var/log na klientu a serveru nevidím žádný jiný soubor který by se plnil chybami apod. find /var/log -mmin -2

klient:
$ ss -s
Total: 1841
TCP:   1019 (estab 622, closed 235, orphaned 17, timewait 234)

ss server:
$ ss -s
Total: 453 (kernel 509)
TCP:   115 (estab 41, closed 57, orphaned 0, synrecv 0, timewait 6/0),
Transport Total     IP        IPv6
*     509       -         -