From owner-freebsd-net Sun Jun 11 22: 9:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from vortex.greycat.com (vortex.greycat.com [207.173.133.4]) by hub.freebsd.org (Postfix) with SMTP id B0DA437B943 for ; Sun, 11 Jun 2000 22:09:52 -0700 (PDT) (envelope-from dann@greycat.com) Received: (qmail 13371 invoked from network); 12 Jun 2000 05:09:49 -0000 Received: from bigphred.greycat.com (HELO greycat.com) (207.173.133.2) by vortex.greycat.com with SMTP; 12 Jun 2000 05:09:49 -0000 Received: (from dann@localhost) by greycat.com (8.9.3/8.9.3) id WAA47816 for net@freebsd.org; Sun, 11 Jun 2000 22:09:44 -0700 (PDT) (envelope-from dann) Date: Sun, 11 Jun 2000 22:09:44 -0700 From: Dann Lunsford To: net@freebsd.org Subject: Re: Strange MTU related (?) problem Message-ID: <20000611220944.A47466@greycat.com> References: <20000611105000.A7581@greycat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from marcs@znep.com on Sun, Jun 11, 2000 at 12:24:05PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 11, 2000 at 12:24:05PM -0600, Marc Slemko wrote: > On Sun, 11 Jun 2000, Dann Lunsford wrote: > > > Turning net.inet.tcp.path_mtu_discovery on or off had no effect, > > Yup, because it is the remote end that is the problem. I thought it might operate by turning off the DF bit. Looking at the code and traces, it apparently doesn't. To tell the truth, I'm not exactly sure what it *does* do :-), but I was in a massive "what the hell" sort of mood. > > (oh, and before I get my rant going I should mention > http://users.worldgate.com/~marcs/mtu/ which contains an overview > of the general PMTU-D horkage issue for people not familiar with > it) Very nice explanation. Now if only we could make reading and understanding the implications a prerequisite for anyone mucking with filters... Your suggestions were cogent, but unfortunately the only systems I have control over are the ones in this house. The complaint about stupidly designed load-balancers echoes one I have about software written in this day and age that doesn't consider security issues (buffer overflows being the most common flaw in *new* software). *sigh* "Against stupidity, the gods themselves contend in vain." It was true when von Schiller wrote it, it remains true today. > > It isn't clear why this suddenly started happening for you. Perhaps there > was some change closer to your end of the world that either increased the > MTU on your systems or decreased the MTU of some link. Or perhaps > slashdot did really change something recently. I suppose it is also > possible that something in the path between you and them started blocking > ICMP can't fragment messages. > I hadn't changed anything here, and my friend who works at my ISP assures me they hadn't changed anything. I did notice that traceroute starts "*"ing its probes at an address *very* close to slashdot, though; slashdot is 64.28.67.48, and the last hop that traceroute shows before starting timeouts is 64.28.66.203. While certainly not conclusive, it lends credence to the "it's at their end" theory. I'm also going to check the other sites exhibiting the problem. > In any case, the proper fix is probably to complain to slashdot and tell > them to fix their probably broken systems. Unfortunately, without access > to both ends, determining if that is the case for sure isn't easy. I'll send Rob a note. Perhaps it will make a difference; he seems to be a reasonable sort.. -- Dann Lunsford The only thing necessary for the triumph of evil dann@greycat.com is that men of good will do nothing. -- Cicero To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message