Dotaz: Prodleva kláves jako ssh klient

[MM]

Ahoj,
po posledním update archlinuxu mám problém s prodlevou kláves když pracuji jako klient na vzdáleném stroji přes ssh (ten se neměnil/neupdatoval, je to ubuntu). Když se přihlásím do konzole, problém není (psaní, mazání, šipky reagují OK), objeví se až po spuštění mc, mcedit, nebo vi. prodleva zmáčknutí klávesy je cca 0.3s - velmi nepříjemné při vzdálené práci na serveru (hlavně v mcedit).
Zkoušel jsem na svém pc (klientu) různé kernely (lts a poslední non-lts), xfce/icewm, rxvt/xterm, putty a zssh místo ssh, vše se chová stejně. Z jiného PC (již dlouho neupdatovaného klienta) problém není.
Síť jiné problémy nevykazuje, ifconfig countery jsou OK (bez errorů).
Prosím o nápady, co ještě zkusit.

---

---

Odpovědi

[NN]

Sit problemy nevykazuje, ale chova se to jako sitovy problem. Pust ssh klienta v mirnem debug rezimu a podivej se do logu..

[MM]

CPU Load average: 0.25 0.29 0.17
PING joura (192.168.1.63) 56(84) bytes of data.
64 bytes from joura (192.168.1.63): icmp_seq=1 ttl=64 time=0.595 ms
64 bytes from joura (192.168.1.63): icmp_seq=2 ttl=64 time=0.507 ms
64 bytes from joura (192.168.1.63): icmp_seq=3 ttl=64 time=0.530 ms

omlouvám se, nenapsal jsem, že je to lokální síť, do Japonska bych to samozřejmě neřešil...
výpisy z wiresharku
poslal jsem "sssssssssssss"

57	2.626964919	192.168.1.63	192.168.1.132	SSH	166	Server: Encrypted packet (len=100)
58	2.626978814	192.168.1.132	192.168.1.63	TCP	66	41938 → 22 [ACK] Seq=593 Ack=1389 Win=594 Len=0 TSval=1437146603 TSecr=4107948
59	2.866842122	192.168.1.132	192.168.1.63	TCP	102	[TCP Retransmission] 41938 → 22 [PSH, ACK] Seq=557 Ack=1389 Win=594 Len=36 TSval=1437146843 TSecr=4107948
60	2.866910817	192.168.1.63	192.168.1.132	SSH	166	Server: Encrypted packet (len=100)
61	2.866926050	192.168.1.132	192.168.1.63	TCP	66	41938 → 22 [ACK] Seq=593 Ack=1489 Win=594 Len=0 TSval=1437146843 TSecr=4107960

občas se objevuje i

663	41.487835530	192.168.1.132	192.168.1.63	SSH	102	Client: Encrypted packet (len=36)
664	41.774552796	192.168.1.63	192.168.1.132	SSH	166	Server: Encrypted packet (len=100)
665	41.774576585	192.168.1.132	192.168.1.63	TCP	66	41938 → 22 [ACK] Seq=5777 Ack=15493 Win=594 Len=0 TSval=1438203422 TSecr=4372102
666	41.774585533	192.168.1.63	192.168.1.132	SSH	166	Server: [TCP Spurious Retransmission] , Encrypted packet (len=100)
667	41.774588453	192.168.1.132	192.168.1.63	TCP	78	[TCP Dup ACK 665#1] 41938 → 22 [ACK] Seq=5777 Ack=15493 Win=594 Len=0 TSval=1438203422 TSecr=4372174 SLE=15393 SRE=15493

na vzdáleném serveru jsou vidět dropped v ifconfig na lokále žádné problémy

[NN]

Jiny lokalni SSH server je ok? Nejaky meziskok v podobe prepinace si kontroloval? Jina komunikace na vzdaleny server (telnet,http) je bez problemu?

[MM]

Je to jen přes switch
Jiný lokální ssh server také blbne (ale až když se spustí vi/mc).
Na telnetu jsem problém neviděl (ale nemám server s telnetem a mc).
zkusil jsem přes router do jiného segmentu lokální sítě na embedded zařízení (busybox) a tam ssh+vi nedělá problémy.
HTTP na server ve stejném segmentu vypadal OK, ale v logu jsem viděl DUP ACK a retransmission také.

[MM]

nicméně dropped na serveru s tím asi nesouvisí, to dělá i (když je zlobivý PC vypnutý) při prohlížení z jiného nezlobivého klienta. Na nezlobivém klienu wireshark neukazuje retransmissions.
ETH controller je tento:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
Je možné, že problém je tam (dají se dočíst problémy s tímto krámem, ale spíš, že nefngoval vůbec)

[drnest]

Tedy se nabízí vyzkoušet to přes jinou síťovou kartu - tedy jestli to jde. Případně wifi, nějaký usb dongle, ... Zkrátka vyhodit z řetězce tu kartu. A pokud to přestane dělat, tak je viník jasný.

[MM]

Ano, rozchodil jsem wifi a nezlobí to...
možno uzavřít,
driver Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) je pravděpodobně v obou kernelech nabořený.
Díky

[lertimir]

ještě bych to zkusil odchytnout na obou stranách současně. Protože to jak čtu komunikace je: 57 Server pošle SSH packet, 58 klient pošle TCP potvrzení, že ho dostal (ACK paket) za jednu desetitisícinu sekundy. nic se neděje. 59 klient znervozní a zopakuje ACK paket (a něco posílá - délka dat v TCP proudu 36 bytů) (po 0,24 sec), 60 server pošle další data. 61 klient pošle ACK k druhému paketu serveru.

A otázka je, proč server nepřijal první ACK packet?

druhý výpis.

663 klient posílá data, 664 server posílá data (a když se to rozbalí tak tam bude správný ACK k poslaným datům klienta), 665 klient posílá ack k datům. 666 server to z nejakého důvodu vyhodnotí chybně a posílá packet 664 znovu (chce to zkontrolovat je-li to skutečně znovu ten samý), 667 znovu poslání TCP ACK packetu 665.

opět otázka proč server nepřijal paket 665?

A další otázka: Proč je Window v TCP proudu je 594 bytů? prorovnal bych se záchytem z jiného klienta.

[MM]

Ještě jsem zkoušel nano, a tam se mi prodleva zdá menší/chvílemi žádná...

[MM]

Jednoznačně pomáhá volba -C (komprese), pak je lepší odezva...
Jinak chová se to např.tak, že když v mcedit napíšu řádku písmen např. sssssssssssssssss , tak poslední písmeno se vypíše po zmíněné době (pokaždé jiné, typicky 0.3s-0.5s)...
Dělá to i při ssh na jiné servery (starý slackware).

[NN]

To zlepsieni s kompresi by mozna napovidalo problem s MTU.

[a1bert]

co ping, zkousel jsi ping?

[majales]

A co CPU stroje jak je vytížené? Pokud má jedno jádro a load je nad nad 1 nebo dokonce 2 tak se to může taky podepsat na odezvě..

[pavele]

Možná se změnilo defaultní šifrování, zkusil bych třeba:

ssh -c aes128-ctr xxx

[MM]

Zkoušel jsem, nepomohlo, spíš to vypadá na síťový problém vysílání

[MM]

CPU vytížení je OK, to jsem kontoloval (CPU je I7čka).
Je zvláštní, že to dělá jen když spustím ten nějaký program, přímo v bashi ne, jako by se nějak změnily timeouty pro odesílání "zbytku" bufferu po DMA přenosu v driverech nebo tak něco. Dělá to tipicky poslední (případně jediný) znak buřtu...
Ping a pod. budu moct vyzkoušet zítra, tipuji pod 1.5 ms (je to lokální síť). Díky za tip s wiresharkem to určitě zkusím...

[lertimir]

Takto se sítové problémy chovají. je třeba to oddebugovat bud v ssh a nebo také wiresharkem. Je potřeba zjistit odpovědi:

1. jak je server daleko v ms? Za jak dlouho přijde odpověď v TCP kanálu?
2. Nezměnilo se něco v definici teminálu? odjede (a přijde) to co potřebují full screen programy v jednom paketu nebo je to rozsekané do více paketů?

[trubicoid2]

tak se to chovalo, kdyz jsem se pripojoval Evropa-Japonsko, s tim nic delat nejde, muzes zkusit treba mosh

[Ja]

Jak to funguje, když se připojíš via ssh přímo na localhosta?

[MM]

To funguje OK