On Tue, 29 Jun 2004, Stephen Hemminger wrote: > On Tue, 29 Jun 2004 13:59:22 -0700 > "David S. Miller" <davem@redhat.com> wrote: > > > On Tue, 29 Jun 2004 13:35:01 -0700 > > Stephen Hemminger <shemminger@osdl.org> wrote: > > > > > FYI - gentoo works for window scale 0..2 and appears to fail for >3. > > > > > > Also, the socket ends up with: > > > > > > State Recv-Q Send-Q Local Address:Port Peer Address:Port > > > ESTAB 0 0 172.20.1.73:34452 198.63.211.232:http > > > ts sack wscale:0,3 rto:332 rtt:66.375/50.5 cwnd:3 > > > > Yes, I've seen this declared in other reports too. > > > > It probably means just that for window scales of 0..2 the misinterpretation > > does not result in a too-small-to-send-data window. > > > > But I'm still confused that the scaled window is being given to the > > receiver, and this makes the connection freeze. I wonder if there is > > a queer box doing NAT or similar in front of the gentoo machine which > > either: > > > > 1) Applies any window scaling to both directions > > 2) Applies window scaling to the wrong direction > > > > and uses this to "help" with dropping of out-of-window TCP segments. > > Unfortunately, this means the default probably means that window scale must be > disabled. An interesting experiment would be to see if other implementations have > the same problem with window scale enabled. Sigh. I ran in to this problem a year or so ago and it was a broken firewall that was mangling the TCP window scale option. I think the firewall was an OpenBSD machine, and I was told the problem went away with an upgrade. I'm curious what they're running here. The boundary 3 is special because it causes SWS avoidance to break. -John - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
