> >This makes ntpd very unhappy, as it can't reach the remote servers anymore.
> >As a workaround I'm killing and restarting ntpd in my ip-up script, but I'm
> >wondering what the real solution would be.
> 
> a better solution would be for ntpd use an ephemeral port for talking
> to servers, just like ntpdate does, and then to close it after it's
> done with a round of polling.  just my opinion.

No, that doesn't fix the problem ntpd has.  ntpd's problem is that it
needs to know the destination address in packets that it receives, and
specify the source address for packets it sends.  The NTP specification
demands this because of how it identifies associations.  ntpdate also
strictly needs this information, but sleazes through without it since it
doesn't maintain long-lived peer sessions.  The daemon can't do this.

The UDP system call interface has traditionally never provided a sensible
way (like the sendmsg()/recvmsg() buffer) to learn destination addresses for
incoming packets or to specify source addresses for outgoing packets.  This
forces the daemon to scan interface configuration to learn all possible
addresses an incoming packet could be validly addressed to (for ntp this
sometimes includes interface broadcast addresses and other grot) and then
open a socket for each so you can deduce the packet's destination by the
socket it arrives on.  All of this is necessary only because the UDP
implementation chucks the bit of information the daemon needs to know
about a packet on the far side of the system call interface.  Fix the
latter, and the daemon could happily operate, for the most part, with
just one socket and without looking at interface configuration at all.
Changes to interface configuration would just work.

> im(ns?)ho, ntpd should *also* periodically re-lookup the addresses for
> hostnames that are its peers/servers.  i have had several annoying
> situations where a host's address changed, the ntp.conf was correct on
> a client/peer, and the host's time slowly drifted *anyway*.  ntpd just
> needs to be restarted, but it's a pain.

Essentially you are suggesting a hack to work around the problems of another
hack implemented to work around the problems of the traditional BSD UDP
system call interface.  Fix the latter (if it isn't already), and fix
ntpd to run with a single unbound socket, and all will be well.

I'm particularly sensitive about this since I've seen Unix boxes running
as the host part of routers which have several thousand interfaces with
several thousand local addresses.  Having to have a daemon which sends
and receives three packets per minute track the address configuration
of several thousand interfaces and open (and poll) several thousand sockets
so it can learn the destination address on those three packets it receives
every minute is just dumb.

Dennis Ferguson