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.

[Vermind]

Transfers do not stall on my machine. They are much faster at times as well. Sysctl gets loaded on bootup, but BEFORE the net module, and that is why the sysctl net settings "went to waste". So I added net to /etc/modules, and everything is perfect now.

I am marking this thread unsolved since steve c still has the same issue.

Steve c, which other fixes/workarounds have you tried? Changing default ssh config (GSSAPI auth and some other things), changing interface MTU, others?
I found that setting a bandwidth limit on scp did the trick when my transfers were stalling. I had approx a 200KB upload rate, so I set the scp limit to 1600. Are You having a problem getting files through at all, or through conveniently? is the "From" machine the one whose sysctl settings you were adjusting?

[steve c]

Transfers do not stall on my machine. They are much faster at times as well. Sysctl gets loaded on bootup, but BEFORE the net module, and that is why the sysctl net settings "went to waste". So I added net to /etc/modules, and everything is perfect now.

Ah, okay. I wasn't aware that it would be affected by ordering like that.

Steve c, which other fixes/workarounds have you tried? Changing default ssh config (GSSAPI auth and some other things), changing interface MTU, others?

I tried changing the MTU on some other advice that I read. I tried 1490, it had no impact. I haven't tried changing the ssh configuration since it isn't limited to ssh for me. HTTP transfers seem to be equally stalled. Downloading updates via the update manager also stalled. I started some update yesterday and went away for 6 hours. It still wasn't finished when I got back. (Admittedly not a solid data point since I don't happen to recall how large the files were.)

I found that setting a bandwidth limit on scp did the trick when my transfers were stalling. I had approx a 200KB upload rate, so I set the scp limit to 1600.

I just tried that. The result was that it went much slower up to 2064 kB and then stalled.

Are You having a problem getting files through at all, or through conveniently? is the "From" machine the one whose sysctl settings you were adjusting?

What happens is when I transfer to my ubuntu machine, it stalls at 2064 kB. After a while, it will resume extremely slowly before stalling again. This continues until the file is eventually transferred.

Transferring from the ubuntu machine seems to work much better. It still stalls, but at different points and it seems to recover more quickly and transfer more before stalling again.

This doesn't happen between my other computers on the same network, just the one running ubuntu. This didn't use to happen either. Unfortunately, since I don't typically transfer large files to or from the machine apart from system updates, I can't say exactly when this started happening, but certainly some point after I installed Hardy. (I wonder if it could be a new kernel I installed at some point.)

Thanks for all of your help.

[steve c]

Oops, I didn't answer one of your questions. I was changing the sysctl settings on the ubuntu machine.