putty zmrzne

Zadnje čase se mi dogaja, da putty zmrzne oz. ne pokaže vsega, kar bi moralo: print screan.
To se zgodi, če se povežem z win mašine. Linux na linux preko ssh dela normalno.

Po tem, ko mi je putty zmrznil, sem se povezal s puttyem še enkrat na isti server. $who -a mi še vedno pokaže, kot da je prvi putty povezan.

Ima kdo idejo v čem bi lahko bil problem?

Use Putty Settings -> Connection and check the Enable TCP Keepalives option.

kolk si pa nastavil keepalive seconds? Daj nekaj cez 10s.

Sem dal 10 sekund. Mislim da ni to problem, ker se to zgodi takoj, ko se logiram in dam $ls -al
Krajše ukaze izpiše brez problema, če pa recimo dam neko inštalacijo, kjer prikazuje več teksta pa vedno zmrzne.

Sem za foro poskusil še ssh na mobitelu. Isti ukaz $ls -al dela brez problema.

MTU na mrežni je nastavljen na 1500. To pomeni, da ne more generirat jumbo frameov?

Jaz sem mislil, da je bolje, da je na 1500, potem nima problemov z jumbo framei, ker jih pač ni.

Ce ima server visji mtu, potem ti bo pac v paket nasopal kolkr gre. Ti bos to sekvenco nehal brati na 1/3 recimo...naslednji paket je ze druga sekvenca. :)

So vse tri masine (linux streznik, linux odjemalec, win odjemalec) v istem LANu (oz. ali je na poti kaksena pozarna pregrada / usmerjevalnik)? Ce zajames promet ob vzpostavitvi seje (paketi s TCP SYN bitom), kaksen je MSS (TCP options - Maximum Segment Size) pri linux odjemalcu in kaksen pri win odjemalcu?

Imas tam, kjer je win odjemalec, PPPoE povezavo v internet, drugje pa ne? Je SSH edina stvar, za katero si opazil, da dela slabo?

Ce ti router ne popravlja MSS, morda lahko za test poskusis tako, da na Win racunalniku interfacu nastavis MTU na 1492 in poskusis, ce je kaj bolje...

netsh interface ipv4 show interface

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
xx 25 1500 connected Ethernet
...

netsh interface ipv4 set interface xx mtu=1492

netsh interface ipv4 show interface

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
xx 25 1492 connected Ethernet
...

PPPoE doda 8 bytov svojih podatkov pred IP header. Ker je na uplinku MTU (Maximum transmission unit - najvecja velikost IP paketa, ki jo naprava lahko poslje preko nekega vmesnika) se vedno 1500 bytov, to naredi tako, da pakete, ki so vecji od 1492 bytov, fragmentira.

V grobem je takole - ce je paket, ki ga poslje racunalnik, velik 1500 bytov, tvoj usmerjevalnik to "razbije" na dva paketa (do fragmentacije pride na IP nivoju, drugi paket sicer ima IP header, nima pa TCP headerja).

Ocitno nekje na poti neka naprava prvi paket spusti skozi (ker vsebuje TCP header, kjer pise, da gre za SSH promet / port 22, ki je v tvojem primeru ocitno dovoljen), drugega (brez TCP headerja) pa ne dovoli - v tvojem primeru je komunikacija obstala, ker je ena stran cakala se na ta drugi, fragmentiran del paketa, ki ga pa seveda ni dobila. TCP sicer to ugotovi in zahteva retransmission, ampak se zgodba pri ponovnem posiljanju ponovi, ker tisti, ki posilja prevelik paket, ne ve, da je prevelik.

Ni tezava v win/linux odjemalcu, ampak v povezavi (tudi odjemalec s kaksnim drugim operacijskim sistemom na isti lokaciji, kjer imas sedaj win odjemalca, bi imel verjetno podobne tezave). Resitev teh tezav je vec (recimo PMTUD - Path MTU Discovery, ki mora za pravilno delovanje omogocati, da se doloceni ICMP paketi vrnejo do posiljatelja originalnega paketa, a se pogosto (zaradi blokiranja na pozarnih pregradah) ne), ce je dovolj samo za TCP protokol, pa precej usmerjevalnikov podpira t.i. MSS clamping.

V splosnem sta lahko tako IP kot TCP header razlicno velika (nekateri podatki v headerjih so obvezni, drugi so opcijski). Minimalna velikost IP headerja je 20 bytov, minimalna velikost TCP headerja ravno tako 20 bytov. Paketi, ki se uporabljajo za prenos aplikacijskih podatkov, praviloma v headerjih nimajo dodatnih (opcijskih) polj, tako da je velikost obeh headerjev skupaj 40 bytov. Na povezavah, kjer je MTU 1500, se torej z enim paketom lahko prenese najvec 1460 bytov aplikacijskih podatkov, ce je MTU manjsi, pa pac ustrezno manj.

MSS - Maximum segment size - je maximalna velikost podatkov, ki se prenasajo v TCP segmentu. Napravi, med katerima se vzpostavlja TCP seja, se med zacetnim 3-way handshake-om (z opcijskimi polji znotraj TCP headerja v paketih, ki imajo nastavljen SYN bit) dogovorita, koliko TCP podatkov bosta najvec posiljala naenkrat. Ti paketi na zacetku (pri vzpostavitvi TCP seje) so majhni (brez aplikacijskih podatkov), tako da se ti paketi naceloma nikoli ne fragmentirajo. Pri MSS clampingu naprava, ki je nekje na poti med odjemalcem in streznikom (ponavadi usmerjevalnik ali pozarna pregrada), spremeni MSS (recimo iz 1460 na 1452), posledicno odjemalec ali streznik v tem primeru nikoli ne poslje vec kot 1452 aplikacijskih podatkov, kar v koncni fazi nanese maksimalno velikost IP paketa (IP header + TCP header + aplikacijski podatki) 1492 bytov (cetudi ima sam nastavljen MTU recimo na 1500) - ko se doda se PPPoE header, je paket se vedno dovolj majhen, da ga ni potrebno fragmentirati. MSS je naceloma lahko pri dvosmerni komunikaciji razlicen (en za v eno smer, drugacen za v drugo), a to v vecini primerov ni smiselno, zato vecina naprav, ki delajo MSS clamping, popravlja to vrednost v obe smeri (in je naceloma vseeno, kje na poti se taksna naprava nahaja, dokler paketi potujejo preko nje).

Ker ocitno nimas naprave, ki bi to podpirala (ali pa imas, a ni vklopljeno), je bila pri tebi resitev pac ta, da si racunalniku zmanjsal MTU, tako da je ze sam v osnovi posiljal manjse pakete. Na vprasanje, ce bi bilo dovolj, da na Linux strezniku popravis MTU, ti zal ne znam odgovoriti (glede na to, da se MSS-a v eno in v drugo smer lahko razlikujeta in da ne vem, kako se v taksnih situacijah obnasajo razlicni operacijski sistemi), verjamem pa, da ne bo tezko poskusiti. Pa po vsem, kar sem napisal, bi naceloma tudi ze moral razumeti, kje je tezava in (morda s pomocjo tcpdumpa ali wiresharka) tudi dokaj hitro sam ustrezno diagnosticirati in resiti vse skupaj. ;)