Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a series of files I need to copy via SCP over a VPN to a remote linux server each night. The files are not large, we're talking about tens of megabytes here, but the file copy almost always stalls after a few seconds. Running the SCP command with -vvv, I see the following over and over throughout the attempted copy process:

debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072

Any thoughts? I see this question being asked in various places out there, but never any answers. Any help would be appreciated.

share|improve this question
I have experienced similar things many times, though I don't have anything that does it reliably right now. It might be interesting to see if hpn-ssh would make a difference. – sfink Mar 9 '10 at 7:12
up vote 5 down vote accepted

Are you allowing ICMP through the VPN? "TCP connection stalls after a few seconds" often translates to "PMTU black hole".

share|improve this answer
so few understand icmp PMTU discovery :-( – The Unix Janitor Aug 29 '12 at 14:53

Similar to @Gerald's response this page gives a good explanation of MTU Discovery and the options when facing this issue.

Also a whitepaper by Cisco that discusses IP Fragmentation, MTU Discovery, and MSS all pertaining to IPSec VPN tunnels but is equally valid for similar situations.

share|improve this answer

Are you running the latest version of whatever ssh servers and clients you're using? I'd also recommend hitting their email lists on this as it seems rather obscure.

share|improve this answer

We had similar spurios problems with scp to some Linux servers (Debian, 2.6.24-etchnhalf).

We were able to do away with the stalls by disabling the TCP variable tcp_sack ("tcp selective acknowledgements") on the remote servers:

sysctl -w net.ipv4.tcp_sack=0

On Debian, tcp_sack is enabled by default. If I read, it should make no sense to disable this option, but in our case, it helped.

You can make this change permanent by adding a line net.ipv4.tcp_sack=0 to /etc/sysctl.conf (on other Linux systems YMMV).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.