Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Oct 2011 05:51:08 -0700
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Paul Schenkeveld <freebsd@psconsult.nl>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: ntpd couldn't resolve host name on system boot
Message-ID:  <20111025125108.GA87567@icarus.home.lan>
In-Reply-To: <20111025092012.GA41065@psconsult.nl>
References:  <4EA5EBB5.3090101@quip.cz> <20111024232750.GA74032@icarus.home.lan> <B26B1B7BC38B4479B103B78B2175234D@multiplay.co.uk> <20111025010327.GA75437@icarus.home.lan> <20111025092012.GA41065@psconsult.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
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 |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111025125108.GA87567>