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

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Post Reply
Message
Author
hkoster1
Posts: 1264
Joined: 2006-12-18 10:10

#16 Post by hkoster1 »

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. :idea:

I would have replied sooner if you had brought this problem up in one of the regular forums, like Hardware or Installation...

rolandas
Posts: 2
Joined: 2007-04-12 11:17

#17 Post by rolandas »

No chances that it is hardware issue. I installed Ubuntu kernel 2.6.17 and all works. But this is not Debian kernel issue, it is general kernel issue I beliewe.

walrus
Posts: 38
Joined: 2006-03-20 01:05
Location: Vaiano, Italy

#18 Post by walrus »

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

Code: Select all

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
and try now to load the site

samething22
Posts: 8
Joined: 2007-03-03 20:22

explanation / workaround

#19 Post by 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:
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. :)

Post Reply