Discussion:
Question about SCP stalling over VPN
(too old to reply)
Dennis Nezic
2010-03-22 17:02:47 UTC
Permalink
I have run into a similar problem, although I don't get any "rcvd
adjust" debug messages -- instead my scp transfers stall -- at a pretty
predictable place too (not exactly, but to within a few megabytes). My
problem ONLY started after I upgraded my kernel (and maybe some other
things :s, from 2.6.19 to 2.6.33). My NFS transfers also started
"stalling", for many minutes (5-15min usually), although they are
retried, and eventually finish. Again, I don't think ANY of these
problems ever happened with my old kernel for a couple years.

During the stalls, netstat says the tcp connection is still
ESTABLISHED, and when I Ctrl-C the stalled scp transfer, the sshd
server logs a "Received disconnect" message. No other debug messages
are shown for me. I'll try to get a tcpdump.
First and foremost, thank you to everyone for your responses. I
checked the MTU on both sides and it's currently 1500 so I'm assuming
it's not a mismatch. My VPN is a pair of old Netscreen 5xp boxes, and
I can't find anything relating to MTU or packet size in the
configuration, but I'm still looking.
Secondly, to answer your question John, There is no persistent
connection between the servers. I could feasibly set up an NFS share
between the two but I have a sneaking suspicion that if the problem
is some sort of packet mangling by the VPN during file transfers, the
actual mechanism used to transfer the file will be irrelevant.
However, I will set this up and test it and report back my results,
most likely next Monday.
Matt,
If you are using ssh do you need to use scp as well? Or is just
plain copy ok?
[...]
I've looked high and low and haven't really come up with anything
definitive. Someone somewhere had mentioned fiddling with MTU
settings, but I'm not really sure what that will accomplish as I
am unfamiliar with what MTU is and does. If this question has
been answered previously, I apologize ahead of time. Thanks!
This does sound like the MTU problem to which you refer. See
http://www.snailbook.com/faq/mtu-mismatch.auto.html for details.
Dennis Nezic
2010-03-24 01:23:49 UTC
Permalink
Err, with "-vvv" I get those exact same debug messages:

"debug2: channel 0: rcvd adjust 131072"

Lots of them. When trying to scp a 1G file to my server it consistently
stalls around 10MB (give or take a few).

What does that debug message mean, and why is it stalling, and why did
it work with my earlier kernel?

To be continued.
Post by Dennis Nezic
I have run into a similar problem, although I don't get any "rcvd
adjust" debug messages -- instead my scp transfers stall -- at a
pretty predictable place too (not exactly, but to within a few
megabytes). My problem ONLY started after I upgraded my kernel (and
maybe some other things :s, from 2.6.19 to 2.6.33). My NFS transfers
also started "stalling", for many minutes (5-15min usually), although
they are retried, and eventually finish. Again, I don't think ANY of
these problems ever happened with my old kernel for a couple years.
During the stalls, netstat says the tcp connection is still
ESTABLISHED, and when I Ctrl-C the stalled scp transfer, the sshd
server logs a "Received disconnect" message. No other debug messages
are shown for me. I'll try to get a tcpdump.
First and foremost, thank you to everyone for your responses. I
checked the MTU on both sides and it's currently 1500 so I'm
assuming it's not a mismatch. My VPN is a pair of old Netscreen 5xp
boxes, and I can't find anything relating to MTU or packet size in
the configuration, but I'm still looking.
Secondly, to answer your question John, There is no persistent
connection between the servers. I could feasibly set up an NFS
share between the two but I have a sneaking suspicion that if the
problem is some sort of packet mangling by the VPN during file
transfers, the actual mechanism used to transfer the file will be
irrelevant. However, I will set this up and test it and report back
my results, most likely next Monday.
Matt,
If you are using ssh do you need to use scp as well? Or is just
plain copy ok?
[...]
I've looked high and low and haven't really come up with
anything definitive. Someone somewhere had mentioned fiddling
with MTU settings, but I'm not really sure what that will
accomplish as I am unfamiliar with what MTU is and does. If
this question has been answered previously, I apologize ahead
of time. Thanks!
This does sound like the MTU problem to which you refer. See
http://www.snailbook.com/faq/mtu-mismatch.auto.html for details.
Dennis Nezic
2010-03-24 20:10:31 UTC
Permalink
The problem only happens with my wireless connection. (madwifi-ng on
the server side, kernel's b43 on the laptop.) With my wired ethernet
connection, the transfers all work. Sigh. I guess there is nothing more
this mailing list can do for me? :P.

(When wired, I'm sure it doesn't matter, but the rcvd adjust
messages steady out at 114688.)
Post by Dennis Nezic
"debug2: channel 0: rcvd adjust 131072"
Lots of them. When trying to scp a 1G file to my server it
consistently stalls around 10MB (give or take a few).
What does that debug message mean, and why is it stalling, and why did
it work with my earlier kernel?
To be continued.
Post by Dennis Nezic
I have run into a similar problem, although I don't get any "rcvd
adjust" debug messages -- instead my scp transfers stall -- at a
pretty predictable place too (not exactly, but to within a few
megabytes). My problem ONLY started after I upgraded my kernel (and
maybe some other things :s, from 2.6.19 to 2.6.33). My NFS transfers
also started "stalling", for many minutes (5-15min usually),
although they are retried, and eventually finish. Again, I don't
think ANY of these problems ever happened with my old kernel for a
couple years.
During the stalls, netstat says the tcp connection is still
ESTABLISHED, and when I Ctrl-C the stalled scp transfer, the sshd
server logs a "Received disconnect" message. No other debug messages
are shown for me. I'll try to get a tcpdump.
First and foremost, thank you to everyone for your responses. I
checked the MTU on both sides and it's currently 1500 so I'm
assuming it's not a mismatch. My VPN is a pair of old Netscreen
5xp boxes, and I can't find anything relating to MTU or packet
size in the configuration, but I'm still looking.
Secondly, to answer your question John, There is no persistent
connection between the servers. I could feasibly set up an NFS
share between the two but I have a sneaking suspicion that if the
problem is some sort of packet mangling by the VPN during file
transfers, the actual mechanism used to transfer the file will be
irrelevant. However, I will set this up and test it and report
back my results, most likely next Monday.
Matt,
If you are using ssh do you need to use scp as well? Or is just
plain copy ok?
[...]
I've looked high and low and haven't really come up with
anything definitive. Someone somewhere had mentioned fiddling
with MTU settings, but I'm not really sure what that will
accomplish as I am unfamiliar with what MTU is and does. If
this question has been answered previously, I apologize ahead
of time. Thanks!
This does sound like the MTU problem to which you refer. See
http://www.snailbook.com/faq/mtu-mismatch.auto.html for
details.
Loading...