[ntp:questions] Re: uk pool problem

David L. Mills mills at udel.edu
Mon Sep 4 00:04:16 UTC 2006


Sachin Kamboj's new code can use ntpq for anything in the configuration 
file. Sachin has moved on to another job and his code, although working, 
needs test and fix. It first needs to survive the recent rewrite of the 
command line parsing, which has changed since he first merged with the 
distribution. A volunteer could have a lot of fun with the new code, 
which by the way has explicit support for the pool function plus a lot 
of other goodies folks have been asking for.

I would suggest to a volunteer that a diff between Sachin's code and the 
base code he has been working on, then apply the diff to the current 
code and fix what breaks.

By the way, the new code parses exactly the same syntax and semantics as 
the present configuration file, including non-reserved words. However, 
it's all syntax-driven and configuration commands can be issued anytime 
via ntpq. And yes, it is MD5 authenticated.


Harlan Stenn wrote:
>>>>In article <44FA4A86.7080905 at ntp.isc.org>, mayer at ntp.isc.org (Danny Mayer) writes:
> Danny> We'd also like to get rid of
> Danny> ntpdc but that requires that ntpq supports some queries that it
> Danny> cannot currently handle. ntpdc uses private mode 7 packets which is
> Danny> much more difficult to maintain while ntpq uses mode 6 packets.
> ntpq does standard mode 6 queries and should be portable across versions and
> implementations.
> ntpdc uses vendor-specific mode 7 queries.
> There is no way to bring up new associations with mode 6 packets.
> This functionality *can* be done with a mode 7 packet.
> I would be happy to see ntpdc simplified (ie, get rid of anything that can
> be done with ntpq), but I can also see the value in having a single program
> that knows when to use a mode 6 packet and when to use a mode 7 packet.
> After all, it is most convenient to see the current peer list when adding or
> removing associations.
> H

More information about the questions mailing list