Date: Mon, 26 Jan 2009 02:30:12 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: lev@freebsd.org, freebsd-net@freebsd.org, Mark Andrews <Mark_Andrews@isc.org>, freebsd-stable@freebsd.org Subject: Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address Message-ID: <20090126002703.J90458@sola.nimnet.asn.au> In-Reply-To: <200901251537.07249.doconnor@gsoft.com.au> References: <200901250113.n0P1DmHe060610@drugs.dv.isc.org> <200901251537.07249.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 25 Jan 2009, Daniel O'Connor wrote:
> On Sunday 25 January 2009 11:43:48 Mark Andrews wrote:
Doug Barton wrote:
> > > I've never used mpd myself, but you might want to try adding the
> > > following line to /usr/local/etc/rc.d/mpd and see if it helps:
> > >
> > > # BEFORE: named
This doesn't help in the case where mpd may take seconds to negotiate
with $provider for a link; always the case on ADSL here anyway, moreso
for dialup. The rc.d script exits after launching mpd, so named will
still start 'right away' while mpd - or ppp - is still negotiating.
I 'solved' this chicken-and-egg by adding an ugly sleep 7 after starting
(mpd &) before exiting the script. Haven't bothered refining what works
once a month or two, but the sleep could be killed by pid from an mpd-up
script as soon as there's a working link. (mpd 4.1 if it matters)
> > mpd should also be fixed as the error code being returned is not
> > approprate. network unreachable is what should be returned.
It's not mpd's error, or message; named knows nothing about mpd, but
does like its specified listen and *-source addresses to exist. This
one looks more like a ill-worded 'no route to host' indication perhaps?
Or trying to listen on the address of the (yet to exist) ng interface?
> I'm not sure that is the whole problem - I found that it would return device
> not configured 'permanently' when I was using it. The link would be up
> (apparently) but nothing passes. Sometimes restarting it would fix it but
> other times it just persistently said the same thing.
>
> It seemed like there was some kernel state that was incorrect and even
> restarting mpd would not fix it.
I've found named requires a proper /etc/rc.d/named stop / start cycle
after all required interfaces are up and there's a default route, here,
and that sleep 7 obviates that for me .. but it's hardly elegant.
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090126002703.J90458>