> On 28-Feb-99 B. James Phillippe wrote:
>> On Sun, 28 Feb 1999, Alan Cox wrote:
>>> The Linux networking traces I've seen with MTU discovery all show it working
>>> correctly and faults at remote sites. I have yet to see a single case where
>>> the problem is the Linux end with 2.0.x
>>
>> The reason I was so suspicious of the problem being at our (Linux) end, is
>> because you can reach the site no problem from the masq/firewall box; just
>> not from the clients. I was also suspicious because such a large number of
>> sites have this problem (though I've since learned not to underestimate the
>> potential for mass ignorance. ;) The masq box and the clients are both
>> reaching the outside through the same interface and MTU (obviously). The
>> problem only occurs with the client. I could be mistaken, but IIRC the
> One of my business partners had this problem a couple of weeks ago, fixed by
> changing the MTU on the gateway/masq box to 1500. What was strange though,
> and _really_ masked the problem was that it was only with certain web sites
> (specifically, the web sites would return in response to a HEAD but not a GET,
> I guessed that this was something to do with the difference in packet size), and
> only the Linux and WinNT boxes inside the network had this problem - the OS/2
> box worked fine. I'll ask him for TCPdumps of his version of the problem, if
> that would help.
It was discussed MANY times before. Four letters from archive to understood
problem:
-- Part 1 --
Subject: A router bug?
Date: Sat, 30 Jan 1999 16:38:22 -0800 (PST)
From: hjl@lucon.org (H.J. Lu)
To: linux-kernel@vger.rutgers.edu (linux kernel)
Hi,
I am using Linux as a gateway/router for my network via SLIP. But for
some sites, I can only access them if I start my netscape on the
router. If I access them from my network, which goes through my
Linux gateway, my netscape just waits there forever. It seems that
netscape sends some bytes to the remote site and wait for response
from the remote site. For some reason, the response never comes.
Is that possible for the Linux gateway doesn't forward those bytes
sent to the remote site under certain conditions? What should I
look for?
Thanks.
-- H.J. Lu (hjl@gnu.org)-- Part 2 -- Subject: Re: A router bug? Date: Sun, 31 Jan 1999 01:57:18 +0000 (GMT) From: alan@lxorguk.ukuu.org.uk (Alan Cox) To: hjl@lucon.org (H.J. Lu) CC: linux-kernel@vger.rutgers.edu
> from the remote site. For some reason, the response never comes. > Is that possible for the Linux gateway doesn't forward those bytes > sent to the remote site under certain conditions? What should I > look for?
If the MTU of the two links is different you should look for outgoing frames through the router with no reply when the size of reply would be large. Thats a clear indication that the remote site has firewalls set up by overpaid underbrained morons from one of the many rich and clueless consulting firms who think blocking all icmp on a firewall is a valid thing to do.
Alan -- Part 3 -- Subject: Re: A router bug? Date: Sat, 30 Jan 1999 17:12:06 -0800 (PST) From: hjl@lucon.org (H.J. Lu) To: alan@lxorguk.ukuu.org.uk (Alan Cox) CC: linux-kernel@vger.rutgers.edu
> > from the remote site. For some reason, the response never comes. > > Is that possible for the Linux gateway doesn't forward those bytes > > sent to the remote site under certain conditions? What should I > > look for? > > If the MTU of the two links is different you should look for outgoing > frames through the router with no reply when the size of reply would be > large. Thats a clear indication that the remote site has firewalls set up > by overpaid underbrained morons from one of the many rich and clueless > consulting firms who think blocking all icmp on a firewall is a valid > thing to do. >
I am not sure if it is the case:
1. I can access the web site in question on the Linux router. 2. Here is the slip interface on the router:
# ifconfig sl0 sl0 Link encap:VJ Serial Line IP inet addr:209.249.10.145 P-t-P:209.249.10.10 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:576 Metric:1 RX packets:2182 errors:0 dropped:5 overruns:1190 frame:1 compressed:0 TX packets:2001 errors:0 dropped:0 overruns:1069 carrier:0 collisions:8 compressed:0
On the remote slip site:
# ifconfig sl0 sl0 Link encap:VJ Serial Line IP inet addr:209.249.10.10 P-t-P:209.249.10.145 Mask:255.255.255.248 UP POINTOPOINT NOTRAILERS RUNNING NOARP MULTICAST MTU:576 Metric:1 RX packets:158898 errors:2049 dropped:0 compressed:0 TX packets:0 errors:0 dropped:0 compressed:284488
Everything seems to match. The only difference is I don't have NOTRAILERS.
Thanks.
-- H.J. Lu (hjl@gnu.org)-- Part 4 -- Subject: Re: A router bug? Date: 31 Jan 1999 08:30:09 +0100 From: Andi Kleen <ak@muc.de> To: hjl@lucon.org (H.J. Lu) CC: linux-kernel@vger.rutgers.edu, alan@lxorguk.ukuu.org.uk
In article <m106lQl-0000V1C@sea.lucon.org>, hjl@lucon.org (H.J. Lu) writes: >> >> > from the remote site. For some reason, the response never comes. >> > Is that possible for the Linux gateway doesn't forward those bytes >> > sent to the remote site under certain conditions? What should I >> > look for? >> >> If the MTU of the two links is different you should look for outgoing >> frames through the router with no reply when the size of reply would be >> large. Thats a clear indication that the remote site has firewalls set up >> by overpaid underbrained morons from one of the many rich and clueless >> consulting firms who think blocking all icmp on a firewall is a valid >> thing to do. >>
> I am not sure if it is the case:
> 1. I can access the web site in question on the Linux router. > 2. Here is the slip interface on the router:
> # ifconfig sl0 > sl0 Link encap:VJ Serial Line IP > inet addr:209.249.10.145 P-t-P:209.249.10.10 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:576 Metric:1 ^^^^^^^
This explains it. Your other box is connected to an ethernet with MTU of 1500. Thus it sends a MSS option of 1500-X into the initial SYN of the TCP connection. Now the other server correctly sets its MSS to 1500-X and sends packets with that size with the Dont-Fragment bit set for PMTU discovery. Once they reach the other end of your slip link they get dropped and the router sends back a ICMP frag-needed to tell the other box to lower its pmtu - but because of the ICMP blocking firewalls set up by people that were so nicely described by Alan it never sees them. It does not happen from your router box, because there the first interface has a 576 MTU which means that TCP only puts a small MSS option in the first SYN, and all packets that are exchanged are small and no pmtu discovery is needed.
One workaround: set the mtu on the gateway route you use on the other box (route add default gw ROUTER mss 576), then the MSS will contain small values from the beginning. It would be better to complain to the sites that don't work, because it is clearly a misconfiguration on their part. Another workaround is to increase the sl0 MTU to 1500bytes.
-Andi
-- end --
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/