Why do my school's servers hate my box?

[celloandy]

I'm a student at George Washington, and have been having problems accessing the School of Engineering's servers, and was wondering if anyone here might have any insight... whenever I try to ssh there terminal box, or access the student webserver (by http, in a browser), the program (ssh or firefox) just hangs. I can't get either of these servers to answer. I don't think my copies of firefox or ssh are broken, because I can ssh to other boxes, and browse to other sites. Also, my box is a dual-boot, and these things work under windows. They also work if I try them from a Gnoppix cd. The only difference I can see between these environments and my main Gentoo one is that the Gentoo install is amd64, but my friend has an amd64 box running suse, and it works fine. Why do you thing the school servers hate me?

Andrew

(btw, the ssh server is hobbes.seas,gwu,edu, and the webserver is student.seas.gwu.edu... they're both Solaris boxes)

[r00tzz]

Works fine here, i tried access from Brazil.

Did you tried to access the sites from another network (another ISP)?
or try cheking your hosts file to see if there is some invalid entries...

just a guess...


EDIT: Sorry for the wrong guess...

[asiobob]

potentially a TCP/IP window resizing issue, are you using kernel 2.6.7 or later? The server or a router in front of those services you say may be broken.

To go back to the default window size

[celloandy]

I'm running 2.6.8, and that tcp default window scale thing did it. Just out of curiousity, though, what did I actually do? Will the change have any negative effects on anything?

Andrew

[allucid]

That also fixed a problem I was having with accessing my university servers from off-campus. I am also interested in more information on the topic. I am familiar with the window resizing you are talking about (sliding window?) but I don't understand why this is causing problems.

[asiobob]

it shouldn't have any negative effect unless you are on a really fast low latency network and are planning to constant move large amounts of data, in which case the default window scaling( what tcp/ip protocol orginially defined) is to small and you won't be able to achieve "maximum" data transfer, so it will still work but not to its full potential.
What you just did by the command is bring it back to line as is with the other distro's you tried probably because they are not running 2.6.7 or greater


IIRC the window field is only 16 bits wide, which meants a max window size of 64kb. Back when this was designed it was MORE than enough. Today its not the case with faster networks.

The solution is "window scaling." In theory it allows for bigger windows, allowing more "in flight" data, it should be backwards compatible as well, but some routers between you and the destination are broken in that they drop such packets.

EDIT: There was a patch which was submitted to the kernel devs, but IIRC would mean you wouldn't have to adjusting the scaling yourself, however it was rejected, and rightfully so (no offence to the author of the code) since workarounds due to buggy routers shouldn't be in the kernel itself -- it promotes router manufacturers from not releasing updated firmware.

if you want more info LWN had an article about window scaling as well, prolly have to google that

[allucid]