[ntp:questions] Re: Need ntpdc command to recreate sockets
mayer at gis.net
mayer at gis.net
Tue Jan 11 14:08:12 UTC 2005
Enrique Perez-Terron wrote:
> On Mon, 2005-01-10 at 14:51, mayer at gis.net wrote:
> > Enrique Perez-Terron wrote:
> > > Hello,
> > >
> > > I am on a DSL account that regularly disconnects me for a minute
> > > then gives me a different IP address. I have added a line to
> > > ntpd whenever the ppp0 network device comes up, but I would like
> > > have ntpd handle the issues internally without loosing the time
> > > statistics.
> > >
> > > It is not enough to instruct ntpd to recreate the peer
> > > it keeps an UDP socket bound to the old IP address, and reuses
> > > socket for all communications.
> > It's harder than you think and is on my list of things to do. We
> > basically need to rescan the interfaces, remove the deleted IP
> > addresses and add the new IP addresses. While it would be possible
> > to implement a scheme via ntpdc to add/delete a specific IP
> > it would not be easy either.
> I already coded a rescan of the interfaces, and began looking at what
> else was needed. Ouch, it seems the local interface IP address is
> for a couple of things!
Great, if you want to attach it to the bugzilla #51 report I can use
it as a basis for integrating it.
> I wonder if it makes sense at all to keep the timing statistics
> associated with the peer while changing the IP address in some
> structure(s). Is the local IP address part of the protocol in all
> cases? Or only for authenticated associations?
There is no basis for assuming that only the IP address changed.
The only way to indicate that would be to add an option to the conf
file to tell it. Otherwise it's equivalent to restarting for that
interface. You also have to be careful in case there's more than
one interface on the system.
> If we have to create new associations, will there be any difference
> just stopping and restarting ntpd?
For most machines probably not except that it would be done
automatically without involving external mechanisms.
> Or is it possible (meaningsfull) to save the statistics, tear down
> association, create a new association (after duly closing the udp
> and opening a new one), and copy the statistics into the new peer
Certainly you can save the statistics. In my view it should be
like tearing down the old association and setting up a new one
for each connection.
> > This problem is logged as bug #51 in bugzilla.
> Thanks! It did not turn up in my earlier searches of the bugzilla.
> The discussion in this bug mentions putting the interface rescan code
> somewhere in the select loop. I was thinking of running the
> rescan when a peer turns unreachable (peer->reach == 0 && o(ld)reach
> 0; ntp_proto.c).
That's undecided as yet, but it's certainly a possibility.
> Thinking about it, once we try to implement anything like this,
> it should be done somewhat more general: Allowing the program to
> discover added/removed/reconfigured interfaces at regular intervals.
> The main advantage I can see is at startup, if ntpd is started before
> the network is up. It would also make the implementation more
> to problems caused by network reconfigurations. It is nice to reduce
> the number of things that system administrators must remember to
> when they need to change something else.
The intent was to implement this in the same way as BIND 9 does which
rescans at a regular (settable) interval.
> Another bug report suggests a general configuration language to
> communications based on local interface addresses as opposed to the
> existing "source" address (remote address) based "restrict" command.
> do not see clearly if this suggestion is orthogonal to the issue at
If you specify specific addresses to listen on then there should
be no need for rescanning so it's not totally orthogonal.
More information about the questions