11

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 '10 at 7:12
7

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 :-( – The Unix Janitor Aug 29 '12 at 14:53
  • 2
    That sounds interesting, but is not totally clear. Could you elaborate on what exactly is going wrong, and how to fix it? – Craig McQueen May 23 '17 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

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

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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