It may not be a Debian/kernel problem at all! My guess would be that you should upgrade the firmware in your DSL router/modem... I had a similar problem in my Linksys WAG200G, and a firmware update solved it.
I would have replied sooner if you had brought this problem up in one of the regular forums, like Hardware or Installation...
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
help needed filing a bug
it loads well to me (2.6.18-4-686, etch fully upgraded)
it maybe the infamous aggressive tcp scaling issue, exposed also in the realease notes for etch
http://www.debian.org/releases/etch/amd ... on.en.html
try to disable tcp window scaling as root
and try now to load the site
it maybe the infamous aggressive tcp scaling issue, exposed also in the realease notes for etch
http://www.debian.org/releases/etch/amd ... on.en.html
try to disable tcp window scaling as root
Code: Select all
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
-
- Posts: 8
- Joined: 2007-03-03 20:22
explanation / workaround
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:
http://inodes.org/blog/2006/09/06/tcp-w ... rnel-2617/
http://kerneltrap.org/node/6723
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.
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:
http://inodes.org/blog/2006/09/06/tcp-w ... rnel-2617/
http://kerneltrap.org/node/6723
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.