From owner-freebsd-rc@FreeBSD.ORG Tue Sep 28 02:20:44 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFB95106564A; Tue, 28 Sep 2010 02:20:44 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB548FC0C; Tue, 28 Sep 2010 02:20:42 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Mon, 27 Sep 2010 22:20:42 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 1844B33C00; Mon, 27 Sep 2010 22:20:42 -0400 (EDT) Date: Mon, 27 Sep 2010 22:20:42 -0400 From: Ed Maste To: Brooks Davis Message-ID: <20100928022042.GA92385@sandvine.com> References: <20100925000435.GA62501@sandvine.com> <20100925183105.GI72897@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100925183105.GI72897@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-rc@freebsd.org Subject: Re: Wait for carrier in /etc/rc.d/defaultroute X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 02:20:45 -0000 On Sat, Sep 25, 2010 at 01:31:05PM -0500, Brooks Davis wrote: > On Fri, Sep 24, 2010 at 08:04:35PM -0400, Ed Maste wrote: > > > The attached patch introduces a defaultroute_carrier_delay variable > > and a change to /etc/rc.d/defaultroute to wait that long before bailing > > out if there are no interfaces with carrier. With the default settings > > defaultroute will wait for five seconds to see if any interface gets > > carrier. The original 30 second wait for a default route to appear is > > unchanged. > > > > Any comments? I'll commit it sometime next week if there's no concern. > > This seems like a reasionable solution. Just checking for carrier > didn't work as well as I'd hoped. Have you tested this on a bridge or > similar interface? No, I've tested only on physical interfaces. The logic for detecting carrier is unchanged from what was there though, so I wouldn't expect any significant change. > It seems like in some senses there's probably something more the nic > could be telling us about it's state so we could do a better job here. > What we really want to know is if we have any dhcp interfaces that have > a chance of getting a lease any time soon so if the interface could say "I think I've got a > cable attached" that would be useful. I agree, but that's not a project I'm ready to take on at the moment :) I wonder how (if) other operating systems handle this. -Ed