Re: 2.6.17: networking bug??

On Tuesday 13 June 2006 20:39, John Heffner wrote: > The best thing you can do is try to find this broken box and inform its > owner that it needs to be fixed. (If you can find out what it is, I'd > be interested to know.) In the meantime, disabling window scaling will > work around the probl

Re: 2.6.17: networking bug??

Mark Lord wrote: Unilaterally following the standard is all well and good for those who know how to get around it when a site becomes inaccessible, but not for Joe User. So lets enable it in the kernel, and let the distros turn it off. The Joe User who isn't a kernel hacker won't be running 2.

Re: 2.6.17: networking bug??

Mark Lord wrote: Further to this, the current behaviour is badly unpredictable. A machine could be working perfectly, not (noticeably) affected by this bug. And then the user adds another stick of RAM to it. This "bug" already existed in 2.6.16 to a certain extent: you were losing out on a l

Re: 2.6.17: networking bug??

> Also, as John Heffner mentioned, even if we could detect the broken > boxes you can't just "turn off window scaling" after it's been > negotiated. It's immutably active for the entire connection once > enabled. In theory you could set a bit in the dst entry and not use it next time you connect

Re: 2.6.17: networking bug??

Rick Jones wrote: One final word about window sizes. If you have a connection whose bandwidth-delay-product needs an N byte buffer to fill, you actually have to have an "N * 2" sized buffer available in order for fast retransmit to work. Is that as important in the presence of SACK? With SAC

Re: 2.6.17: networking bug??

On Tue, Jun 13, 2006 at 05:49:21PM -0400, Mark Lord wrote: > > > David Miller wrote: > >.. > >First, you are getting window scaling by default with the older > >kernel too. It's just a smaller window scale, using a shift > >value of say 1 or 2. > > > >What these broken middle boxes do is ignore

Re: 2.6.17: networking bug??

From: Rick Jones <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 15:40:53 -0700 > > One final word about window sizes. If you have a connection whose > > bandwidth-delay-product needs an N byte buffer to fill, you actually > > have to have an "N * 2" sized buffer available in order for fast > > retran

Re: 2.6.17: networking bug??

One final word about window sizes. If you have a connection whose bandwidth-delay-product needs an N byte buffer to fill, you actually have to have an "N * 2" sized buffer available in order for fast retransmit to work. Is that as important in the presence of SACK? rick jones - To unsubscribe

Re: 2.6.17: networking bug??

From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 17:49:21 -0400 > I suppose the most important objection to our current behaviour > is that this behaviour *changes* when something totally unrelated > (to Joe User) happens: adding or removing a stick of RAM. We are pretty much required

Re: 2.6.17: networking bug??

From: Chase Venters <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 17:09:16 -0500 (CDT) > Does anyone have any interesting statistics on how often end-users > are likely to run into this crap? I think it's much less likely than the ECN stuff, by a long shot. - To unsubscribe from this list: send the

Re: 2.6.17: networking bug??

Mark From everything I have read so far (which admittedly hasn't been everything) it sounds like the firewall in question was a ticking timebomb. If 2.6.17 hadn't set it off, something else might very well have done so. Or, if you prefer another metaphore, 2.6.17 was simply the last in a s

Re: 2.6.17: networking bug??

On Tue, 13 Jun 2006, John Heffner wrote: In the last couple years, we've added code that can automatically size the buffers as appropriate for each connection, but it's completely crippled unless you use a window scale. Personally, I think it's not a question of *whether* we have to start u

Re: 2.6.17: networking bug??

David Miller wrote: .. First, you are getting window scaling by default with the older kernel too. It's just a smaller window scale, using a shift value of say 1 or 2. What these broken middle boxes do is ignore the window scale entirely. So they don't apply a window scale to the advertised

Re: 2.6.17: networking bug??

From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Jun 2006 15:08:59 -0400 > Err.. no, the networking stack simply decided to become incompatible > with certain sites, as a result of the user adding more RAM to their > machine. Let's discuss some facts. First, you are getting window scaling by de

Re: 2.6.17: networking bug??

On 6/13/06, John Heffner <[EMAIL PROTECTED]> wrote: Though I haven't gotten my hands on it, I believe Windows will soon have this capability, too. I'm sure Windows is big enough that whenever they turn this on, it will flush out all these boxes pretty quickly. We could wait for them to do it fi

Re: 2.6.17: networking bug??

Mark Lord wrote: Linus Torvalds wrote: It's not like there aren't broken boxes out there, and it might be better to make the default buffer sizes just be low enough that window scaling simply isn't an issue. I suspect that the people who really want/need window scaling know about it, and co

Re: 2.6.17: networking bug??

Linus Torvalds wrote: On Tue, 13 Jun 2006, John Heffner wrote: The best thing you can do is try to find this broken box and inform its owner that it needs to be fixed. (If you can find out what it is, I'd be interested to know.) In the meantime, disabling window scaling will work around the p

Re: 2.6.17: networking bug??

Linus Torvalds wrote: On Tue, 13 Jun 2006, John Heffner wrote: The best thing you can do is try to find this broken box and inform its owner that it needs to be fixed. (If you can find out what it is, I'd be interested to know.) In the meantime, disabling window scaling will work around the p

Re: 2.6.17: networking bug??

On Tue, 13 Jun 2006, John Heffner wrote: > > The best thing you can do is try to find this broken box and inform its owner > that it needs to be fixed. (If you can find out what it is, I'd be interested > to know.) In the meantime, disabling window scaling will work around the > problem for yo

Re: 2.6.17: networking bug??

Mark Lord wrote: John / David: Any ideas on what's gone awry here? Yes, you have some sort of a broken middlebox in your path (firewall, transparent proxy, or similar) that doesn't correctly handle window scaling. Check out this thread:

Re: 2.6.17: networking bug??

Mark Lord wrote: .. The site www.everymac.com is still not browseable until setting /proc/sys/net/ipv4/tcp_window_scaling===0. There's one other difference I see in the tcpdump traces. The first packets from each trace below show different values for "wscale". The old (working) kernels use "ws

Re: 2.6.17: networking bug??

.. The site www.everymac.com is still not browseable until setting /proc/sys/net/ipv4/tcp_window_scaling===0. There's one other difference I see in the tcpdump traces. The first packets from each trace below show different values for "wscale". The old (working) kernels use "wscale 2", whereas 2

Re: 2.6.17: networking bug??

Mmm. I notice that 2.6.17 has a new sysctl related to this stuff: /proc/sys/net/ipv4/tcp_workaround_signed_windows It makes no difference whatsoever for me here when varied while /proc/sys/net/ipv4/tcp_window_scaling==1. The site www.everymac.com is still not browseable until setting /proc/sys

Re: 2.6.17: networking bug??

Mark Lord wrote: .. The differences I see are widely varying "window sizes". What would cause this? This is from (working) 2.6.16.18: IP silvy.localnet.56224 > 216-145-246-23.rev.dls.net.www: . ack 1 win 1460 IP silvy.localnet.56224 > 216-145-246-23.rev.dls.net.www: P 1:607(606) ack 1 win 14