Some pages not loading in Iceweasel (Debian 5.0)

ODJ · 04-06-2009, 02:27 AM

repo, ifconfig gives

Code:

eth0      MTU:1500  

lo       MTU:16436

(not crazy about giving out private info, so i omitted the rest seeing you asked for the MTU. (lo = loopback))

Tried the fix from the other thread suggested by mrclisdue; woohoo!! Finally it works! Even hotmail and facebook! I'm spinning around in my chair with joy! :P Thanks to all who've helped! Seeing it was the fix suggested in the other thread, i can only assume it had to do with the ip4_window_scaling=0. Will see now if undoing my earlier actions have any effect, so my situation might be of help to anyone in the future with a similar problem.

(i now used the method of "echo 0 > /proc/sys/net/ipv4/tcp_window_scaling", so i'll probably have the same problem after a reboot..? Will see and report back on that)

The fix given in that thread:

Quote:

Originally Posted by hobbsc

Greetings, folks.

My name is Christopher M. Hobbs, I'm the Network Administrator for the City of Siloam Springs a member of the openSUSE Community and a member of the openSUSE-GNOME team.

The issue posted here is a known issue and has nothing to do with our webserver. The problem we're having is with our firewall and it has been on the table for some months now. The firewall will soon be replaced, so in order to fix things on your end (at least until we have a new firewall), you will need to adjust your TCP Window Scaling options.

In order to do this temporarily, you can issue the following command (as root):

sysctl -w net.ipv4.tcp_window_scaling=0

Should that command fail, give this one a shot:

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

To permanently disable TCP Window Scaling, issue the following command as root and reboot:

echo '"net.ipv4.tcp_window_scaling=0" >> sysctl.conf'

I'll personally write the original author of this post from my City account should he not return to this thread.

Thank you for your diligent efforts.
cmh

FYI: i have not installed nscd, so that played no role in fixing my problem.

ODJ · 04-07-2009, 09:18 AM

After reboot, i indeed have the same problem, so (for now or untill there's a fix) i'll disable it permanently..

repo · 04-07-2009, 10:36 AM

You know this has to do with the firewall?
Perhaps you can talk with the IT people.

ODJ · 04-08-2009, 01:55 PM

Quote:

Originally Posted by repo

You know this has to do with the firewall?
Perhaps you can talk with the IT people.

I did not know that, repo (haven't had time to dive deeper into it after the initial relief of finding a solution).

If it's too technical to get into here just say so, but how come something like that does affect Linux, but not Windows? And what setting should be changed in our firewall to solve this issue?

farslayer · 04-08-2009, 02:14 PM

Window Scaling is an automated function of the TCP protocol implemented in 1992... he should know about it..

This issue has been around for a while
http://lwn.net/Articles/92727/

Quote:

The TCP window field, however, is only 16 bits wide, allowing for a maximum window size of 64KB. The TCP designers must have thought that nobody would ever need a larger window than that. But 64KB is not even close to what is needed in many situations today. The solution to this problem is called "window scaling." It is not new; window scaling was codified in RFC 1323 back in 1992. It is also not complicated: a system wanting to use window scaling sets a TCP option containing an eight-bit scale factor. All window values used by that system thereafter should be left-shifted by that scale factor; a window scale of zero, thus, implies no scaling at all, while a scale factor of five implies that window sizes should be shifted five bits, or multiplied by 32. With this scheme, a 128KB window could be expressed by setting the scale factor to five and putting 4096 in the window field.

To keep from breaking TCP on systems which do not understand window scaling, the TCP option can only be provided in the initial SYN packet which initiates the connection, and scaling can only be used if the SYN+ACK packet sent in response also contains that option. The scale factor is thus set as part of the setup handshake, and cannot be changed thereafter.

The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.

ODJ · 04-09-2009, 03:30 AM

Thanks, farslayer. I've given this info to our IT dept. as a startingpoint.

I don't expect they'll do much with it (seeing Windows (and Mac, seemingly) is preconfigured for this and i'm the only one in the office on Linux).

farslayer · 04-09-2009, 07:11 AM

They may not be able to do anything on their side.. the link provided earlier by mrclisdue shows an issue with a firewall, that can't be fixed until the firewall vendor does something about it.. in the mean time disabling it on your box is the only recourse.

Best of luck !!