From owner-freebsd-stable@FreeBSD.ORG Tue Oct 25 13:42:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1F4E1065670 for ; Tue, 25 Oct 2011 13:42:06 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 036AB8FC1E for ; Tue, 25 Oct 2011 13:42:05 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138] (may be forged)) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id p9PDfx4O097924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Oct 2011 15:42:04 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p9PDfxR4097923 for freebsd-stable@freebsd.org; Tue, 25 Oct 2011 15:41:59 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Tue, 25 Oct 2011 15:41:59 +0200 From: Paul Schenkeveld To: freebsd-stable@freebsd.org Message-ID: <20111025134159.GA96607@psconsult.nl> References: <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> <20111025010327.GA75437@icarus.home.lan> <20111025092012.GA41065@psconsult.nl> <20111025125108.GA87567@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111025125108.GA87567@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: ntpd couldn't resolve host name on system boot 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: Tue, 25 Oct 2011 13:42:06 -0000 On Tue, Oct 25, 2011 at 05:51:08AM -0700, Jeremy Chadwick wrote: > On Tue, Oct 25, 2011 at 11:20:12AM +0200, Paul Schenkeveld wrote: > > On Mon, Oct 24, 2011 at 06:03:27PM -0700, Jeremy Chadwick wrote: > > > The one shortcoming of netwait is that it doesn't support waiting for > > > multiple NICs. Some people have dual-homed environments where they > > > really would like to wait for both, say, em0 and em1, to come up and be > > > functional before any more scripts are started. I left that as a > > > project for someone else, but it's something that should be added given > > > its importance. > > > > How would you like to see multiple interfaces implemented: > > > > - All interfaces must be up at the same time > > - Probe interfaces one by one, proceed to the next when an interface > > up or bail out when any interface stays down until the loop times > > out > > 1) Each interface should be checked in the order specified. > 2) Each ping probe should be done using that interface (ping -I). >From ping(8): -I iface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. I believe that for unicast the interface used is determined by looking up the destination address in the routing table (unless overridden by a packet filter that changes the next hop). Another way to influence the next hop selection and the outgoing interface is using setfib(1) but apart from rc.d/jail I see no fib support in rc.conf at all. > 3) In the case of success, the next interface should be checked (e.g. go > back to step #1 but for the next interface defined. > 4) In the case of failure, output a message on-screen (similar to what > we already do) and continue on with the next interface check. > > So I imagine the variables for this would need to become something like: > > netwait_em0_ip="4.2.2.1 4.2.2.2" > netwait_em1_ip="192.168.1.1 192.168.1.2" > > You get the idea -- think ifconfig_* in style. This also suggests that ping can be forced to send out packets thru a certain interface which I think is misleading. Where I see the testing of multiple interfaces becoming important is in the case where interfaces are bonded using lagg(4). I usually have RTP disabled on server ports but started to see problems with ntpd and other services when I started to use LACP trunks. Paul Schenkeveld