[ntp:questions] Re: Need ntpdc command to recreate sockets

Enrique Perez-Terron enrio at online.no
Mon Jan 10 18:44:15 UTC 2005


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 and
> > then gives me a different IP address.  I have added a line to restart
> > ntpd whenever the ppp0 network device comes up, but I would like to
> > have ntpd handle the issues internally without loosing the time
> > statistics.
> >
> > It is not enough to instruct ntpd to recreate the peer structures, as
> > it keeps an UDP socket bound to the old IP address, and reuses this
> > socket for all communications.

[snip]
> 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 address,
> 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 used
for a couple of things!

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?

If we have to create new associations, will there be any difference from
just stopping and restarting ntpd?

Or is it possible (meaningsfull) to save the statistics, tear down the
association, create a new association (after duly closing the udp socket
and opening a new one), and copy the statistics into the new peer
structure?

>  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 interface
rescan when a peer turns unreachable (peer->reach == 0 && o(ld)reach !=
0; ntp_proto.c).

Thinking about it, once we try to implement anything like this, perhaps
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 resilent
to problems caused by network reconfigurations.  It is nice to reduce
the number of things that system administrators must remember to handle
when they need to change something else.

Another bug report suggests a general configuration language to restrict
communications based on local interface addresses as opposed to the
existing "source" address (remote address) based "restrict" command. I
do not see clearly if this suggestion is orthogonal to the issue at hand
here.

> 
> I will try to get to it as soon as I have the IPv6 multicasting
> issues resolved.

Great! 

> Danny

- Enrique
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ntp.org/pipermail/questions/attachments/20050110/cbf801f5/attachment.pgp>


More information about the questions mailing list