From owner-freebsd-stable@FreeBSD.ORG Thu Aug 17 07:16:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E188F16A4E2; Thu, 17 Aug 2006 07:16:54 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343C743D53; Thu, 17 Aug 2006 07:16:53 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k7H7GqRX095377; Thu, 17 Aug 2006 11:16:52 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k7H7GpxR095376; Thu, 17 Aug 2006 11:16:52 +0400 (MSD) (envelope-from yar) Date: Thu, 17 Aug 2006 11:16:51 +0400 From: Yar Tikhiy To: Brooks Davis Message-ID: <20060817071651.GB94460@comp.chem.msu.su> References: <20060815040736.2f85f090.drl@MyBSD.org.my> <9405D801-3435-419A-9541-E1A9B2CF26D2@lassitu.de> <20060816081130.GB81271@comp.chem.msu.su> <20060816145419.GB62485@lor.one-eyed-alien.net> <20060816155844.GA85503@comp.chem.msu.su> <20060816171524.GA63928@lor.one-eyed-alien.net> <20060816204927.GA73369@heff.fud.org.nz> <20060816205913.GA69877@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060816205913.GA69877@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.9i Cc: drl@MyBSD.org.my, freebsd-stable@freebsd.org, Stefan Bethke , Andrew Thompson Subject: Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2006 07:16:55 -0000 On Wed, Aug 16, 2006 at 03:59:13PM -0500, Brooks Davis wrote: > On Thu, Aug 17, 2006 at 08:49:27AM +1200, Andrew Thompson wrote: > > On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote: > > > On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote: > > > > On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote: > > > > > On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote: > > > > > > > > > > > > Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're > > > > > > using when they exit? Flushing all routes then would be rather > > > > > > harmful. I'm glad I haven't updated to a newer -stable yet then :-) > > > > > > > > > > In general, no since tun interfaces can not be destroyed. > > > > > > > > Did you mean "in particular"? :-) > > > > > > > > The problem can be triggered by destroying any interface that can > > > > be destroyed. Just imagine getting rid of a defunct gif tunnel on > > > > a remote router, or removing an unused vlan, and totally losing > > > > connectivity to the router due to its default route having been > > > > flushed. The scenario still can be quite unpleasant. I'd rather > > > > change the default for $removable_route_flush to NO and let the > > > > kernel choose which routes should be flushed upon the physical > > > > ejection or software destruction of an interface. Note that this > > > > doesn't include static_routes_${ifn}, which are handled separately > > > > by pccard_ether_stop(). > > > > > > Agreed. That code shouldn't be on by default. I've disabled in it HEAD > > > and will MFC in a few days. As another poster said, I'm not even sure > > > it should exist as an option. > > > > Thanks for fixing this up, it certainly was odd to be flushing routes in > > userland. I have one more bug report from the ifnet/devd change to look > > at where renamed interfaces give some sort of an error. > > It is a rather weird bit of code. It deletes all IPv4 routes on exit. > I suspect it's a hack left over from before interface removal really > worked. I may just delete the code in HEAD after the MFC. I think we > could also remove the arp flush or move it into "netif stop" and narrow > it with the -i option. The -i option may not work in that case because the interface has ceased to exist by the time devd(8) gets the notification and runs /etc/pccard_ether. It could be better just to remove the arp flush completely. The kernel should take care of the arp entries by itself. Thanks! -- Yar