Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
(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:
Originally Posted by hobbsc
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:
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.
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.