| Summary: | scp transfers from remote cygwin machine fail with ssh versions >= 4.6 | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Charles Davis <cdavis> |
| Component: | scp | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | major | CC: | dtucker |
| Priority: | P2 | ||
| Version: | 4.6p1 | ||
| Hardware: | ix86 | ||
| OS: | Linux | ||
|
Description
Charles Davis
2010-01-13 20:56:57 AEDT
I suspect you have a device in your network path that cannot handle large TCP windows, probably window scaling. One of the changes in the 4.7 release was: * The SSH channel window size has been increased, and both ssh(1) sshd(8) now send window updates more aggressively. These improves performance on high-BDP (Bandwidth Delay Product) networks. Previously this was limited to 64k, which is not enough to exercise TCP window scaling. You can confirm this by looking at the "SendQ" field in the connection in the netstat output on the sending side (this is on Linux, I don't know how to get the equivalent data on Windows). If the number is non-zero and doesn't decrease this is almost certainly the problem. You can also try disabling window scaling. On Linux, that's "echo 0 >/proc/sys/net/ipv4/tcp_window_scaling". I don't know about Windows but presumably it's in the registry somewhere. You'll only need to disable it on one end and retry the copy. (In reply to comment #1) > I suspect you have a device in your network path that cannot handle > large TCP windows, probably window scaling. > > One of the changes in the 4.7 release was: > > * The SSH channel window size has been increased, and both ssh(1) > sshd(8) now send window updates more aggressively. These improves > performance on high-BDP (Bandwidth Delay Product) networks. > > Previously this was limited to 64k, which is not enough to exercise TCP > window scaling. You can confirm this by looking at the "SendQ" field > in the connection in the netstat output on the sending side (this is on > Linux, I don't know how to get the equivalent data on Windows). If the > number is non-zero and doesn't decrease this is almost certainly the > problem. > > You can also try disabling window scaling. On Linux, that's "echo 0 > >/proc/sys/net/ipv4/tcp_window_scaling". I don't know about Windows > but presumably it's in the registry somewhere. You'll only need to > disable it on one end and retry the copy. This: "echo 0 >/proc/sys/net/ipv4/tcp_window_scaling" completely fixes the problem. Thanks loads. As far as I am concerned it is fixed. So I am changing the status. However, before I came to you fellows, I searched extensively and there seems to ba a lot of instances of this problem. Is there somewhere I can add a FAQ or soemthing like that?? Charles Davis (In reply to comment #2) > This: > "echo 0 >/proc/sys/net/ipv4/tcp_window_scaling" > completely fixes the problem. Thanks loads. You're welcome. What type of ADSL device is it, so that we can add it to the mental list of broken ones? I suspect it's creating a firewall state only in the ethernet -> ADSL direction, and since the window scale option is only on the first packet, when you connect from outside the state doesn't know the connection has window scaling and thus gets the TCP windows wrong. If this is the case, you would see that scping out would work (ie the same data transfer direction but initiated from the other end). > As far as I am concerned it is fixed. So I am changing the status. > > However, before I came to you fellows, I searched extensively and there > seems to ba a lot of instances of this problem. Is there somewhere I > can add a FAQ or soemthing like that?? There's http://www.openssh.com/faq.html. If you want to write something I'll be happy to review and/or add it, but it's not a very common problem (or at least, it's likely that the network brokenness would be noticed long before anyone starts trying to scp files around). (In reply to comment #3) In reply to comment #2) > > This: > > "echo 0 >/proc/sys/net/ipv4/tcp_window_scaling" > > completely fixes the problem. Thanks loads. > > You're welcome. > > What type of ADSL device is it, so that we can add it to the mental > list of broken ones? > Its some sort of Cisco router. When I disabled its firewall, the problem went away. Further screwing around with the firewall has caused me to get myself locked out from the installation, hence the lack of detail. When I get back in I'll provide specifics. THanks again. > I suspect it's creating a firewall state only in the ethernet -> ADSL > direction, and since the window scale option is only on the first > packet, when you connect from outside the state doesn't know the > connection has window scaling and thus gets the TCP windows wrong. If > this is the case, you would see that scping out would work (ie the same > data transfer direction but initiated from the other end). > > > As far as I am concerned it is fixed. So I am changing the status. > > > > However, before I came to you fellows, I searched extensively and there > > seems to ba a lot of instances of this problem. Is there somewhere I > > can add a FAQ or soemthing like that?? > > There's http://www.openssh.com/faq.html. If you want to write > something I'll be happy to review and/or add it, but it's not a very > common problem (or at least, it's likely that the network brokenness > would be noticed long before anyone starts trying to scp files around). Offending router is Linksys RV082. Seems to work fine if the firewall is disabled. RV082 router no longer exhibits the problem is the latest (2.0.0.19) firmware is used. Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1 |