Mark Rogers <[EMAIL PROTECTED]> writes:
[snip]
> telnet 206.60.51.4 80
> I get connected and type "GET /" and the page comes down the screen.
>
> On *any* machine on our network (all runnng Rh5.0 + Updates) however,
> the same thing results in the
> connection timing out after I issue the GET / command.
> I have tried this with only one machine and the router plugged into the
> HUB.
>
> Also just tried it with a computer (my Win95) plugged directly into the
> router with a crossover ether cable and it's the same thing, a request
> of that page times out.
I think you have a problem with ip fragmentation and firewalls blocking the
intermediate router's ICMP(?) "packet too big" message.
Basically between the 2 extremes (using tcp) they negotiate a mss for
the connection. The maximum packets they will send are thus the mss +
20 (ip) + 20 (tcp) bytes. If one of the intermediate routers can't
handle a packet of this size normally it will fragment it into smaller
packets so the fragmented packets reach their final destination.
However when people start putting firewalls and they set the DF (don't
fragment bit) on the ip packets as they pass through the firewall.
This tells DF bit tells routers to NOT fragment packets if they are
too big, but to advise the sender that they don't fit. Normally I
think the router sends an ICMP reply to the sender telling it the
packet doesn't fit so the sender can send a smaller packet.
If this ICMP packet gets lost (or filtered out by a firewall) then the
sender doesn't know the packet isn't reaching the destination, and
will retry but sending the same packet will achieve the same "useless"
result. tcp connections only result in small packets being exchanged,
but after that an http request typically involves sending a stream of
bytes from the server. Typically this may be larger than 1500 bytes.
Result: connection, disconnection due to timeout. (no received data).
This is more noticeable when you use a MTU of 1500 (or larger) at both
ends because there ARE routers which use smaller MTUs and thus NEED to
fragment packets. I think some default Windows clients use smaller
MTU values on their modems which therefore makes the
negotiated packet sizes smaller and the problem less noticeable (it
may not appear). If you use ethernet and then a firewall (packet filter
such as ip masquerading) to "get onto the net" the MTU of your machine will be
the ethernet MTU of 1500 bytes. This will be the be where you see significant
problems.
It's hard to check if this exists, but try doing pings with packets of large
size
ping -s 1500 <host>
sends 1500+ bytes to the host, and you may find that these "large packet pings"
don't make it to the destination, but a standard 56 byte ping works, you know
you've got a problem. If you look at the packets with tcpdump, check for the
DF bit being sent on any packets either to you or from the other end.
If this is the case try and ping the intermediate hosts with the large packets
and find where you can't "get through". This is probably your troublesome
router/firewall etc.
It's a bit late, but I think the gist of this is correct if not the exact
details. I've seen several sites in Spain exhibit this behaviour and it's
really irritating. Often I think the site admins don't really know that
they have a problem as it may not be apparent under most circumstances.
To explain the problem requires patience and them understanding some of the
more exotic parts of tcp/ip that most people normally ignore.
I hope I'm not completely off here, but someone will certainly breath down
my neck if I am. time to go to work (it's now the morning).
Simon
--
Simon J Mudd, Madrid SPAIN * Tel: +34-91-559 2854 * e-mail: [EMAIL PROTECTED]
[short messages - from radio hams only] ----> [EMAIL PROTECTED]
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
