16

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.

1
  • 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

8

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

2
  • 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
7

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

3

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).

1

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
  1. find out your Path MTU

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

    ip link set eth0 mtu 1196
    

    (note that this is temporary)

1

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 .