Received: by taz.hyperreal.com (8.6.12/8.6.5) id RAA19888; Mon, 25 Mar 1996 17:29:04 -0800 Received: from bauhaus.organic.com by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id RAA19879; Mon, 25 Mar 1996 17:29:02 -0800 Received: (from cliff@localhost) by bauhaus.organic.com (8.7.3/8.6.12) id RAA06210; Mon, 25 Mar 1996 17:28:45 -0800 (PST) Date: Mon, 25 Mar 1996 17:28:45 -0800 (PST) From: Cliff Skolnick To: new-httpd@hyperreal.com cc: Apache Mailing List Subject: Re: Obscure MTU problem In-Reply-To: <9603252330.aa02562@gonzo.ben.algroup.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Yep...the braindead ISP are not changing the livingston default MTU from 1006 to something reasonable for a slip line. The thing is that many BSD based SLIP implementations use a cluster of MBUFs to hold a complete packet. When you use CSLIP, you need 128 bytes to hold the extra header info. SO: Normal cluster mbuf size = 1024 Overhead for CSLIP needs 128 max MTU for the slip line can only be 1024-128, oops :) I have a competent ISP and they still mess up my line every once and a while. Since you are using a >512 MTU for remote hosts I assume you are using solaris, BSDI 2.1, or possibly a new IRIX os with dynamic path MTU detection. BTW it could also be an ICMP problem at any router, path MTU detection must get back an ICMP messages. Beware of firewalls :) Cliff On Mon, 25 Mar 1996, Ben Laurie wrote: > Hi, > > I've just been investigating a problem with our new Apache based > webserver where people using dialups with _some_ ISPs were having extreme > difficulty with our site (intermittently). The symptom at their end was that > they got connected but then hang indefinitely waiting for the data. At our end > we see connections for the data sitting at FIN_WAIT_1 with lots of stuff in > the send queue. > > I seem to have solved this problem by setting the MTU to 512 (default 1500). > SCO 5 is uses Path MTU Discovery (a lot of implementations use MTU=512 for all > nonlocal nets) which is probably the cause of the problem. We don't have any > such problem with a SCO 3 box and an SGI on the same net. > > Any thoughts, anyone? > > Cheers, > > Ben. > > -- > Ben Laurie Phone: +44 (181) 994 6435 > Freelance Consultant and Fax: +44 (181) 994 6472 > Technical Director Email: ben@algroup.co.uk > A.L. Digital Ltd, URL: http://www.algroup.co.uk > London, England. > -- Cliff Skolnick cliff@organic.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759