scp and rsync stall when transferring from Ubuntu hardy heron 8.04

[Vermind]

Hi,
After I upgraded to Hardy, it seems that scp and rsync no longer transfer files properly. Scp stalls somewhere after 2000KB, and rsync stalls after a few files, I haven't determined the limit. The issue could be fixed from my workplace's environment by a reduced --bwlimit with rsync, but from another location I cannot transfer files reliably either to, or from, my Hardy desktop, when the other end is also a Hardy computer.

I am seeing this:

$ scp gdm-themes.tar.gz drache:dev/.
gdm-themes.tar.gz                              28% 2112KB   1.7MB/s   00:03 ETA
gdm-themes.tar.gz                              33% 2448KB   0.0KB/s - stalled -

I read about a workaround by setting a lower MTU on the interface in question, but it did not help.
I also tried playing around with the MTU values using:
sudo ping -f -v -c 10 -s somenumber target.host.name
and it appeared I get packet loss (20-30%) on all mtu values, except values exceeding 3000 (which does not make sense since I can't set that on my wireless interface, 2200 seems to be the maximum).

Further research into this has yielded no positive results. I went and downloaded the newest OpenSSH 5.1, compiled and installed it, to no avail; transfers from this computer still stall. I am fairly certain it is not the ssh. This occurs on both of my Ubuntu 8.04 machines: My 64-bit desktop, which is using the 8139too network module for an RTL network card, and my laptop, which uses atheros-based wireless.

My desktop had wondershaper installed. I removed it to see if that was causing the problem, but the problem remains.

Has anyone else run into this? any other workarounds?
Thanks.

[steve c]

I am seeing this as well, at least with scp. I haven't tried rsync. Unfortunately, I have no work around.

[willca]

I had similar transfer problems with my wifi. Try adding this at the end of your /etc/sysclt.conf and then reload it via sysclt -p

net.core.rmem_default = 524288
net.core.rmem_max = 524288
net.core.wmem_default = 524288
net.core.wmem_max = 524288
net.ipv4.tcp_wmem = 4096 87380 524288
net.ipv4.tcp_rmem = 4096 87380 524288
net.ipv4.tcp_mem = 524288 524288 524288
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_fack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_ecn = 0
net.ipv4.route.flush = 1

[Vermind]

Hello,
thank You very much, willca!
This fixes it. No stalls with scp, at least on the local network. I am getting stuff at 1.6MB per second, and successfully transferred a 300MB file. Wider testing to take place later.

Thanks again!

[steve c]

I had similar transfer problems with my wifi. Try adding this at the end of your /etc/sysclt.conf and then reload it via sysclt -p

This didn't change anything for me. My transfers still fail at 2064 kB.

[Vermind]

steve c, I just noticed the same. A transfer uploaded from my server still stalled. This was after a reboot from the original fix, so, I said sysctl -p, and tried again. It did not stall. Seems that my sysctl is not being loaded properly at startup. How about you? Does this help?

[steve c]

steve c, I just noticed the same. A transfer uploaded from my server still stalled. This was after a reboot from the original fix, so, I said sysctl -p, and tried again. It did not stall. Seems that my sysctl is not being loaded properly at startup. How about you? Does this help?

I'm afraid not. I didn't reboot. I can't imagine why /etc/sysctl.conf wouldn't be read at boot though. You sure that running sysctl -p after boot actually changed something?

Maybe try restarting and running

sysctl -a > pre
sysctl -p
sysctl -a > post
diff -u pre post

and see if the settings are actually different.

[vhex]

I had similar transfer problems with my wifi. Try adding this at the end of your /etc/sysclt.conf and then reload it via sysclt -p

Thank you SO MUCH!

[Vermind]

Hello,
It appears stalls are occurring again when I transfer to the University Linux server. When I first tried the suggested net modifications, transfers there did not stall. Something is wrong...

[steve c]

Well, you can chalk my problems up to my switch dying. Apparently the few different ports I tried in my tests had all failed while the others were working so it seemed like not a switch problem.

When different symptoms appeared on my other machines (not running ubuntu), I noticed that setting my speeds from 1000baseT to 100baseT caused a significant speed up, but it was still slow. Wireshark showed a large number of duplicate tcp packets being sent. I pulled the switch out of the network and replaced it with a slower router and now my network issues have disappeared.

Thanks for all of the help and my apologies for wasting your time.