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.

  • 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, 2010 at 7:12

6 Answers 6


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

  • 2
    so few understand icmp PMTU discovery :-( Aug 29, 2012 at 14:53
  • 3
    That sounds interesting, but is not totally clear. Could you elaborate on what exactly is going wrong, and how to fix it? May 23, 2017 at 4:32

Similar to @Gerald's response this page http://www.netheaven.com/pmtu.html 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. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml


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 http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html, 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).


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.

  1. find out your Path MTU

    ping -M do -s 1472 host.domain
    PING host.domain ( 1472(1500) bytes of data.
    ping: sendmsg: Message too long
    ping: local error: Message too long, mtu=1196
    ping -M do -s 1168 host.domain
    PING host.domain ( 1168(1196) bytes of data.
    1176 bytes from icmp_seq=1 ttl=60 time=283 ms
  2. set up that MTU for your network connection

    ip link set eth0 mtu 1196

    (note that this is temporary)


Setting sysctl -w net.ipv4.tcp_sack=1 on both ends of the trasfer helped me. Thanks to earlier answer by @flight

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .