Dotaz: scp - nejde kopirovat velke soubory na vzdaleny pocitac

[Gilhad]

Mam problem a uz nevim co dal otestovat nebo zkusit:

 $ scp -P 22 gNOSVN.2.0.tar.gz user@aa.bb.cc.dd:
Password: 
gNOSVN.2.0.tar.gz                  100%  648KB 647.9KB/s   00:00 

Vysledek naskoci okamzite po zadani hesla a dal uz nic, do promptu se to nevrati. Pro jina IP (zz.xx.cc.vv napriklad) to funguje bez problemu. (Pro kraticke soubory taky.) Na cilovem pocitaci se vytvori prazdny soubor gNOSVN.2.0.tar.gz a visi tam ssh:

30350 ?        Ss     0:00  \_ sshd: user [priv]
30355 ?        S      0:00  |   \_ sshd: user@notty
30356 ?        Ss     0:00  |       \_ scp -t .

Na vzdaleny pocitac se da zalogovat:

$ ssh user@aa.bb.cc.dd

funguje to normalne. Kdyz jsem na tom pocitaci nalogovany, tak

 $ scp -P 22 jmeno@pu.vo.dni.IP:gNOSVN.2.0.tar.gz .
Password: 
gNOSVN.2.0.tar.gz                  100%  648KB 647.9KB/s   00:00 

probehne bez problemu a soubor prenese. (Cili stahnout jde, natlacit nikoli)

Stejne tak se soubor da na vzdalenem pocitaci scp-ckovat sem a tam bez problemu:

$ scp -P 22 gNOSVN.2.0.tar.gz user@127.0.0.1:
Password: 
gNOSVN.2.0.tar.gz                  100%  648KB 647.9KB/s   00:00 
$ scp -P 22 gNOSVN.2.0.tar.gz user@192.168.1.100:
Password: 
gNOSVN.2.0.tar.gz                  100%  648KB 647.9KB/s   00:00 

Cili se zda, ze ten pocitac sam o sobe funguje, ale neco po ceste to zmrsi ... (ten pocitac je za nejakym firewalem/NATem, od ktereho nemam klice - ssh-cknout se zkrz zvladnu, scp funguje jen obracene)

Ma nekdo ideu, cim by to mohlo byt, nebo jak to resit? Admin toho NATu je (asi) spis malo zkuseny a obtizne dostupny, takze idealne primo co tam ma upravit, pokud se to da takhle usoudit?

---

---

Odpovědi

[Gilhad]

Tak jsem jeste vyzkousel ruzne velikosti a takhle to vypada:

 # scp -P 22 * user@aa.bb.cc.dd:
Password: 
000.tmp                                                                                            100%    0     0.0KB/s   00:00    
001.tmp                                                                                            100% 1024     1.0KB/s   00:00    
002.tmp                                                                                            100% 2048     2.0KB/s   00:00    

jeden kilobyte se prenese okamzite, pri dvou to vytuhne ...

(Obracene tahani se tvari, ze zvlada stovky kB/s)

[Gilhad]

Ostatne se zda, ze jakykoli pokus prenest tam trochu vic dat naraz skonci vytuhnutim (tedy i copy paste textu prez ssh - kratke projdou hned, o fous delsi ani po mnoha minutach)

[Filip Jirsák]

Napadá mne jenom problém s MTU, že by malé pakety prošly, ale velké pakety na hranici ne. Zkuste tu komunikaci sledovat tcpdumpem – nejlepší by bylo na obou stranách, ale to asi bude obtížné. Leda byste ji přesměroval do souboru a pak nějak k sobě dostal ten soubor.

[Gilhad]

Zatim umim jen na jedne strane ... posilam soubory, 1405 B projde, 1406 uz ne. Packety tcpdump hlasi velikosti 1440 (ano) 1448 (uz ne)

.cz.ssh: P 12773:12837(64) ack 3454 win 165 <nop,nop,timestamp 524620035 150010234>
.cz.ssh: P 12837:14277(1440) ack 3502 win 165 <nop,nop,timestamp 524620041 150010237>
.cz.ssh: P 14277:14341(64) ack 3550 win 165 <nop,nop,timestamp 524620047 150010239>
.cz.ssh: P 14341:15781(1440) ack 3598 win 165 <nop,nop,timestamp 524620052 150010241>
.cz.ssh: P 15781:15845(64) ack 3646 win 165 <nop,nop,timestamp 524620058 150010244>
.cz.ssh: P 15845:17285(1440) ack 3694 win 165 <nop,nop,timestamp 524620063 150010246>
.cz.ssh: P 17285:17349(64) ack 3742 win 165 <nop,nop,timestamp 524620069 150010248>
.cz.ssh: P 17349:18789(1440) ack 3790 win 165 <nop,nop,timestamp 524620075 150010250>
.cz.ssh: P 18789:18853(64) ack 3838 win 165 <nop,nop,timestamp 524620081 150010253>
.cz.ssh: P 18853:20293(1440) ack 3886 win 165 <nop,nop,timestamp 524620086 150010255>
.cz.ssh: P 20293:20357(64) ack 3934 win 165 <nop,nop,timestamp 524620092 150010257>
.cz.ssh: P 20357:21797(1440) ack 3982 win 165 <nop,nop,timestamp 524620098 150010260>
.cz.ssh: P 21797:21861(64) ack 4030 win 165 <nop,nop,timestamp 524620104 150010262>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620109 150010264>
.cz.ssh: P 23309:23317(8) ack 4078 win 165 <nop,nop,timestamp 524620109 150010264>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620164 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620274 150010266>
.cz.ssh: F 23317:23317(0) ack 4078 win 165 <nop,nop,timestamp 524620490 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620494 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620934 150010419>
.cz.ssh: . 23701:25149(1448) ack 4174 win 165 <nop,nop,timestamp 524621182 150009572>

Je mozne, ze nekde je velikost dana na 1500. Na nekolika dalsich strojich, kde to funguje, se to zastavilo na hodnote 988 a packety se zacaly delit (= slo jich vic za sebou, jakmile to presahlo hranici).

Da se nekde na cilovem stroji nastavit, aby chtel mensi velikost?

[Filip Jirsák]

To je potřeba omezit na tom stroji, kde ten problém vzniká. I kdybyste to nastavil na druhém konci, budou se jen pakety fragmentovat po cestě, ale zdrojový počítač se je pokusí odeslat vcelku, a opět to neprojde. Ale pokud je to problém s MTU, je to problém, který může postihnout jakoukoli komunikaci v té síti, a administrátor by to měl řešit.

[Gilhad]

Tak jsem to (nejak) vyresil - pro dnesek top funguje a uvidime, jak dal, ale snad taky :)

Pridal jsem do /etc/conf.d/net nasledujici radek:

mtu_eth0=1000

a restartoval net.eth0

Ted uz se kopirovat da a vse se chova rozumne (aspon na prvni pohled). Cilovy pocitac pouziva male packety, sshd na nem to pozna a nahlasi scp-cku a prez sit to proleze. (IMHO se neco zmenilo na tom NATu, co nemam pod kontrolou, ale cert vi. Hlavni je, ze to ted funguje a daji se prenaset data rozumne)

[Michal Kubeček]

I kdybyste to nastavil na druhém konci, budou se jen pakety fragmentovat po cestě, ale zdrojový počítač se je pokusí odeslat vcelku, a opět to neprojde

Pro TCP spojení tomu lze předejít, viz target TCPMSS