Subject: Re: Local IP addresses changing
To: Dennis Ferguson <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 08/25/2000 14:40:17
>> >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
>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" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."