Date: Sun, 11 Jun 2000 22:09:44 -0700 From: Dann Lunsford <dann@greycat.com> To: net@freebsd.org Subject: Re: Strange MTU related (?) problem Message-ID: <20000611220944.A47466@greycat.com> In-Reply-To: <Pine.BSF.4.20.0006111209250.45740-100000@alive.znep.com>; from marcs@znep.com on Sun, Jun 11, 2000 at 12:24:05PM -0600 References: <20000611105000.A7581@greycat.com> <Pine.BSF.4.20.0006111209250.45740-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000611220944.A47466>