bizarre lack of HTTP response problem

[bigtomrodney]

How about changing the user agent string?

[samething22]

Hey bigtom. Yeah, that's one of the first things I tried. It didn't help. In fact, since the problem is cross-browser (including even wget), the problem is definitely independent of the user-agent string.

[rcgreen]

How about if you enter the IP address into your browser instead of the name?

[samething22]

How about if you enter the IP address into your browser instead of the name?

Yeah, unfortunately, that does not work either.

I am still baffled about this. What a weird bug. I am still trying to figure out which package is responsible.

[samething22]

I have just confirmed that this problem infects Ubuntu 'feisty fawn' as well.

[wookiehentai]

Hey, guys. I noticed that no one has posted anything on this one for a while, but I figured I would go ahead and add what I know. I have three Gentoo Linux machines which cannot access ureg.ohio-state.edu. It doesn't have anything to do with the browser. For some reason, the firewall protecting this web server is denying me access to port 80. I can get to the site on my wife's windows computer. I have tried this with two different browsers (and several user agent strings), along with wget and a php script I wrote to fetch web pages.
When I use the network analyzer tool nmap on ureg.ohio-state.edu, it shows ports 21, 23, 80, and 515 unfiltered (meaning that the firewall is not blocking them). However, when I try to add any options like specifying the source port or IP address for the probe, the firewall closes port 80 (the port for web server applications) off from access to my computer. Running the same scan shows only ports 21, 23, and 515 as unfiltered. I seems that the firewall is actively blocking my computer off from port 80. Given that this happens in other distributions, I wouldn't consider it a bug in a particular version of a distro.

[samething22]

Recently I found out what is going on with this bug.

The problem has to do with larger default buffer sizes for TCP window scaling in recent Linux kernel versions. If there is an improperly configured router between you and the server you're trying to reach, it will create a bottleneck and you'll get no data from the server. The long and the short of it is that it is not a Linux bug.

Here are some better, more detailed explanations:
John’s Tidbits » Blog Archive » TCP Window Scaling and kernel 2.6.17+
Linux: Window Scaling on the Internet | KernelTrap

The solution I have used (and I've had to do it again whenever I've updated my kernel) is to change the values in /proc/sys/net/ipv4/tcp_wmem and /proc/sys/net/ipv4/tcp_rmem. The new values should be "4096 16384 131072" and "4096 87380 174760" respectively. This sets the window scaling buffer back to its earlier/smaller size.

[wookiehentai]

Thank you very much. Worked like a charm.