From owner-freebsd-stable@FreeBSD.ORG Tue Oct 25 12:51:10 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 BC751106566B for ; Tue, 25 Oct 2011 12:51:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id A1DD58FC1A for ; Tue, 25 Oct 2011 12:51:10 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta07.emeryville.ca.mail.comcast.net with comcast id p0qn1h0011GXsucA70r3Rz; Tue, 25 Oct 2011 12:51:03 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id p0kD1h00j1t3BNj8U0kEFH; Tue, 25 Oct 2011 12:44:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4C1D2102C31; Tue, 25 Oct 2011 05:51:08 -0700 (PDT) Date: Tue, 25 Oct 2011 05:51:08 -0700 From: Jeremy Chadwick To: Paul Schenkeveld Message-ID: <20111025125108.GA87567@icarus.home.lan> References: <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> <20111025010327.GA75437@icarus.home.lan> <20111025092012.GA41065@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111025092012.GA41065@psconsult.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org 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 12:51:10 -0000 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). 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. > Another shortcoming: ipv6 support... > > The patch below adds ipv6. > > One caveat, ping6 is used if a word in netwait_ip contains at least a > colon so hostnames in netwait_ip are always pinged using ipv4. > > {snip} Others will need to test IPv6 support -- I do not use it/have it available. It's a matter of opinion, but for IPv6 hosts/addresses, there should be a separate variable, probably netwait_ipv6 (or netwait_XXX_ipv6 if you go with the above ideal). The problem is that our existing ipv6 variables in rc.conf all conform with ipv6_*, so I'm not sure what people prefer. But then maybe the netwait_ip variable should be named netwait_*_ipv4... I'll let others hash this out, but I would prefer the former, since then you end up with something like this: netwait_em0_ipv4="4.2.2.1 4.2.2.2" netwait_em0_ipv6="fe80::202:b3ff:fe1e:8329" (And in this case you would want to test IPv4 connectivity *as well* as IPv6; two separate IP layers, thus both be tested separately; e.g. if 4.2.2.1 responds, don't just consider em0 working necessarily, because there may be daemons that are IPv6-centric that depend on packets flowing through em0. Those using tunnel brokers, however, probably won't benefit from this since netwait starts before such brokers/daemons). You get the idea. The problem is that this breaks the existing variable syntax and will upset a lot of existing users. Hmm... Not sure about this one. Gosh, I could really go either way. One final point, regarding ping6: ping6 lacks the -t argument that ping has. This is bad bad bad. In fact, I have to state up front that adding IPv6 support **should not** be done to this script until ping6 supports -t. I cannot stress this enough. The -t 1 piece is *very* important for proper behaviour. The nuances of the flag often come as a surprise to people. I can look at the ping code to figure out how -t works internally and probably submit a patch for ping6 that does this, but of course I have no way to test it. :-) IPv6 support is something that others will need to work on in general though -- I do not use it, so others are better-suited. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |