Les Mikesell wrote:
On 11/19/10 3:16 PM, Michael D. Berger wrote:
On my intranet, I sometimes transfer large files, about 4G, to an CentOS old box that I use for a web server. I transfer with ftp or sftp. Usually, before the file is complete, the transfer "stalls". At that point, ping from the destination box to the router fails. I then deactivate the net interface on the destination box and then activate it. Ping is then successful, and the transfer is completed. The transferred file is correct, as verified with sha1sum.
All connections are via cat6 wire.
So what do you think? Should I try changing the net card? Any tests to run? Any other suggestions?
I haven't seen anything like that, at least in many years so it probably is hardware related - but make sure your software is up to date. As a workaround, you might try using rsync with the --bwlimit option to limit the speed of the transfer - and the -P option so you can restart a failed transfer from the point it stalled on the last attempt.
This does ring a bell, but the circumstances were a bit different. In our case we were transferring large files between "home" and a remote site. SFTP/SCP transfers were stalling part-way through in an unpredictable manner. It turned out to be a bug in the selective acknowledgment functionality in the TCP stack. Short story, adding the following line to /etc/sysctl.conf fixed the issue:
net.ipv4.tcp_sack = 0
Of course, you can set it on-the-fly using the sysctl command:
sysctl -w net.ipv4.tcp_sack=0
It helped in our case, no way of telling if it will help you. As usual, your mileage may vary.