>> >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.

wouldn't a fresh udp-based socket() and connect() provide this
functionality to ntpd?  as long as it made a new one each time it was
polling...

>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.

setsockopt(s, IPPROTO_IP, IP_RECVDSTADDR, ...) in conjunction with
recvmsg() works rather well.  it did for me, at least.  certainly,
scanning the configured interface list periodically and opening
sockets on each address is a little easier...maybe.

>> 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.

no...i think you need to read what i said again.  in plainer language,
in the ntp server on fribl.for.com is using sqab.trup.com as a peer or
a server, and sqab's ip address changes in the dns, sqab will
presumably be rebooted.  fribl, on the other hand, will continue to
send polls to the *old* address, since ntpd has *no way of knowing*
that the address has changed.  i was simply suggesting that it
re-lookup all server/peer addresses every now and then.  once every
six hours...once ever day or so...something like that.

>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.

right.  in this case, you would be much better off with an ntpd that
used IP_RECVDSTADDR in conjunction with recvmsg().

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."