ntpq - standard NTP query program -

From: Harlan Stenn Date: Fri, 30 Jun 2000 08:14:20 +0000 (-0000) Subject: ChangeLog, authopt.htm, ntpq.htm, release.htm: X-Git-Tag: NTP_4_0_99_K~22 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4d23155eca18c8daa831a267a50dda5a8d445400;p=thirdparty%2Fntp.git ChangeLog, authopt.htm, ntpq.htm, release.htm: * html/release.htm: * html/ntpq.htm: * html/authopt.htm: Updates from Dave Mills bk: 395c56dcSXExEeYqA-SXH6s23HtC8w --- diff --git a/ChangeLog b/ChangeLog index c9bcbd6afa..34925774b5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -2,6 +2,11 @@ * configure.in: 4.0.99j3 + * html/release.htm: + * html/ntpq.htm: + * html/authopt.htm: + Updates from Dave Mills + * ntpd/ntp_request.c (dns_a): Don't call crypto_public for now... * ntpd/ntp_proto.c (receive): Follow the TEST wiggles (peer_xmit): TAI support diff --git a/html/authopt.htm b/html/authopt.htm index 36f896a9fe..c418bce53a 100644 --- a/html/authopt.htm +++ b/html/authopt.htm @@ -28,9 +28,9 @@ functions involve only public values, which considerably simplifies key distribution and storage.

Authentication is configured separately for each association using -the key or autokey subcommands on the peer, +the key or autokey subcommands on the peer, server, broadcast and manycastclient commands -as described in the Configuration Options page. +as described in the Configuration Options page. The authentication options described below specify the suite of keys, select the key for each configured association and manage the configuration operations. @@ -40,13 +40,13 @@ configuration commands require cryptographic authentication. This flag can be set or reset by the enable and disable configuration commands and also by remote configuration commands sent by a ntpdc program running in another machine. If this flag is -enabled, new broadcast client and symmetric passive associations and -remote configuration commands must be cryptographically authenticated -using either symmetric-key or public-key schemes. If this flag is -disabled, these operations are effective even if not cryptographic -authenticated. It should be understood that operating in the latter mode -invites a significant vulnerability where a rogue hacker can seriously -disrupt client timekeeping. +enabled, which is the default case, new broadcast client and symmetric +passive associations and remote configuration commands must be +cryptographically authenticated using either symmetric-key or public-key +schemes. If this flag is disabled, these operations are effective even +if not cryptographic authenticated. It should be understood that +operating in the latter mode invites a significant vulnerability where a +rogue hacker can seriously disrupt client timekeeping.

In networks with firewalls and large numbers of broadcast clients it may be acceptable to disable authentication, since that avoids key @@ -79,31 +79,31 @@ identifier to authenticate their messages. Keys and related information are specified in a key file, usually called ntp.keys, which should be exchanged and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP -associations, additional keys can be used as passwords for the ntpq and ntpdc +associations, additional keys can be used as passwords for the ntpq and ntpdc utility programs.

When ntpd is first started, it reads the key file and installs the keys in the key cache. However, the keys must be activated -before they can be used with the trusted command. This allows, -for instance, the installation of possibly several batches of keys and -then activating or deactivating each batch remotely using -ntpdc. This also provides a revocation capability that can be -used if a key becomes compromised. The requestkey command -selects the key used as the password for the ntpdc utility, -while the controlkey command selects the key used as the -password for the ntpq utility. +with the trusted command before use. This allows, for instance, +the installation of possibly several batches of keys and then activating +or deactivating each batch remotely using ntpdc. This also +provides a revocation capability that can be used if a key becomes +compromised. The requestkey command selects the key used as the +password for the ntpdc utility, while the controlkey +command selects the key used as the password for the ntpq +utility.

Public-Key Scheme

The original NTPv3 authentication scheme described in RFC-1305 continues to be supported; however, in NTPv4 an additional authentication scheme -called autokey is available. It uses MD5 message digest, RSA public-key -signature and Diffie-Hellman key agreement algorithms available from -several sources, but not included in the NTPv4 software distribution. In -order to be effective, the rsaref20 package must be installed -as described in the README.rsa file. Once installed, the -configure and build process automatically detects it and +called autokey is available. It uses MD5 message digest, RSA +public-key signature and Diffie-Hellman key agreement algorithms +available from several sources, but not included in the NTPv4 software +distribution. In order to be effective, the rsaref20 package +must be installed as described in the README.rsa file. Once +installed, the configure and build process automatically detects it and compiles the routines required. The autokey scheme has several modes of operation corresponding to the @@ -113,43 +113,47 @@ special cookie which can be computed independently by the client and server. In symmetric modes the cookie is constructed using the Diffie-Hellman key agreement algorithm. In other modes the cookie is constructed from the IP addresses and a private value known only to the -server. Multicast and symmetric modes use in addition a variant of the -S-KEY scheme, in which a pseudo-random key list is generated and used in -reverse order. These schemes are described along with an executive -summary, current status, briefing slides and reading list, on the Autonomous Authentication page.

The cryptographic values used by the autokey scheme are incorporated as a set of files generated by the ntp_genkeys program, including the DES/MD5 -private keys, RSA public/private key pair, and the Diffie-Hellman +href=genkeys.htm>ntp_genkeys program, including the +symmetric private keys, public/private key pair, and the agreement parameters. See the ntp_genkeys page for a description of the formats of these files. They contain cryptographic values generated by the algorithms of the rsaref20 package and are in printable ASCII format. All file names include the timestamp, in NTP seconds, following the default names given below. Since the file data are derived from random values seeded by the system clock and the file name includes -the timestamp, every generation produces a different file. +the timestamp, every generation produces a different file and different +file name. -

The ntp.keys file contains the private DES/MD5 keys. It must +

The ntp.keys file contains the DES/MD5 private keys. It must be distributed by secure means to other servers and clients sharing the same security compartment and made visible only to root. The ntpkey file contains the RSA private key. It is useful only to the machine that generated it and never shared with any other daemon or -application program, so must be made visible only to root. The -ntp_dh file contains the Diffie-Hellman parameters. It is +application program, so must be made visible only to root. + +

The ntp_dh file contains the agreement parameters. It is necessary that all servers and clients of a security compartment share a -single ntp_dh file, but it does not matter which one. This file -can be distributed using insecure means, since the data are public -values. +single set of parameters, but it does not matter which ntp_dh +file generates them. The servers load the parameters directly from the +file, while the clients load them indirectly from the servers using the +autokey protocol. This file can be also be distributed using insecure +means, since the data are public values.

The ntpkey_host file contains the RSA public key, -where host is the name of the host. Each configured -server or peer association requires the public key -file associated with the particular server or peer to be installed at a -default location or as specified by the commands below. In addition, -public key files are required for all configured associations, including +where host is the name of the host. Each server +or peer association requires the public key associated with the +particular server or peer to be loaded either directly from the file or +indirectly from the server using the autokey protocol. In addition, +public keys are required for all configured associations, including those that might be mobilized by multicast servers or symmetric peers. These files can be widely distributed and stored using insecure means, since the data are public values. @@ -157,11 +161,17 @@ since the data are public values.

Due to the widespread use of interface-specific naming, the host names used in configured and mobilized associations are determined by the Unix gethostname() library routine. Both the -ntp_genkeys program and the run-time protocol derive the name -of the public key file using the name returned by this routine. While it -is usually necessary to configure the private key file name and -timestamp, the server and peer public file names are normally obtained -directly from the server or peer. +ntp_genkeys program and the autokey protocol derive the name of +the public key file using the name returned by this routine. While every +server and client is required to load their own public and private keys, +the public keys for each client or peer association can be obtained from +the server or peer using the autokey protocol. Note however, that at the +current stage of development the authenticity of the server or peer and +the cryptographic binding of the server name, address and public key is +not yet established by a certificate authority or web of trust. +Therefore, when the most secure requirements apply, the public keys and +agreement parameters should be loaded from files, rather than using the +autokey protocol.

Key Management

@@ -170,16 +180,47 @@ which is normally in a shared filesystem in NFS-mounted networks and avoids installing them in each machine separately. The default can be overridden by the keysdir configuration command. However, this is not a good place to install the private key file, since each machine -needs its own file. A suitable place to install it is /etc, -which is normally not in a shared filesystem. The location can be -overridden by the crypto configuration command. - -

All cryptographic keys and parameters should be regenerated on a -periodic basis, like once per month. The ntp_genkeys program uses the same timestamp extension for all files generated at one time, so each generation is distinct and can be readily recognized. However, by default the file names expected by ntpd are without the timestamp extension. A simple approach to key maintenance is to distribute newly generated public files without the extension and install them in each server and client while in normal operation. This avoids the need to edit the NTP configuration file for each new generation. - -

A server and its clients load a new key generation in the following way. The server and its clients have loaded the old generation at startup and are operating normally. The new generation is installed at the server and its clients while the old generation is running. The server then restarts ntpd and loads the new generation, with result the clients no longer can authenticate. After a few minutes the clients time out and restart the protocol from the beginning, with result the new generation is loaded and operation continues normally. - -

Key distribution can be done semi-automatically using a set of shell scripts and the Unix rdist utility. Each server runs the ntp_genkeys program from a cron job, and uploads the relevant public files to a common location accessible to the rdist utility. At that location a script selects one of the Diffie-Hellman files and bundles it along with the latest generation of public-key files for rdist, which downloads them to all servers and clients. +needs its own file. A suitable place to install it is in /etc, +which is normally not in a shared filesystem. + +

The recommended practice is to keep the timestamp extensions when +installing a file and to install a link from the default name (without +the timestamp extension) to the actual file. This allows new file +generations to be activated simply by changing the link. However, +ntpd parses the link name when present to extract the extension +value and sends it along with the public key and host name when +requested. This allows clients to verify that the file and generation +time are always current. However, the actual location of each file can +be overridden by the crypto configuration command. + +

All cryptographic keys and related parameters should be regenerated +on a periodic and automatic basis, like once per month. The +ntp_genkeys program uses the same timestamp extension for all +files generated at one time, so each generation is distinct and can be +readily recognized in monitoring data. While a public/private key pair +must be generated by every server and client, the public keys and +agreement parameters do not need to be explicitly copied to all machines +in the same security compartment, since they can be obtained +automatically using the autokey protocol. However, it is necessary that +all primary servers have the same agreement parameter file. The +recommended way to do this is for one of the primary servers to generate +that file and then copy it to the other primary servers in the same +compartment using the Unix rdist command. Future versions of +the autokey protocol are to contain provisions for an agreement protocol +to do this automatically. + +

Servers and clients can make a new generation in the following way. +All machines have loaded the old generation at startup and are operating +normally. At designated intervals, each machine generates a new +public/private key pair and makes links from the default file names to +the new file names. The ntpd is then restarted and loads the +new generation, with result clients no longer can authenticate +correctly. The autokey protocol is designed so that after a few minutes +the clients time out and restart the protocol from the beginning, with +result the new generation is loaded and operation continues as before. A +similar procedure can be used for the agreement parameter file, but in +this case precautions must be take to be sure that all machines with +this file have the same copy.

Authentication Commands

@@ -187,64 +228,63 @@ periodic basis, like once per month. The ntp_genkeys program uses the s

autokey [logsec]

Specifies the interval between regenerations of the session key list -used with the autokey feature. Note that the size of the key list for +used with the autokey protocol. Note that the size of the key list for each association depends on this interval and the current poll interval. The default value is 12 (4096 s or about 1.1 hours). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.

controlkey key

Specifies the key identifier to use with the ntpq program, -which uses the standard protocol defined in RFC-1305. This program is -useful to diagnose and repair problems that affect ntpd -operation. The key argument to this command is a key -identifier for a trusted key, where the value can be in the range 1 to -65534, inclusive.

Specifies the key identifier to use with the ntpq utility, which uses the standard +protocol defined in RFC-1305. The key argument is the +key identifier for a trusted key, where the value can be in the range 1 +to 65534, inclusive.

crypto [privatekey file] [publickey file] [dhparms file]

This command requires the NTP daemon build process be configured -with the RSA library. The presence of this command causes the daemon to -load the host RSA private key file, public key file and Diffie-Hellman -parameter file. If one or more files are left unspecified, the default -names are used as described above. Following are the subcommands:

+with the RSA library. This command activates public-key cryptography and +loads the required RSA private and public key files and the optional +Diffie-Hellman agreement parameter file, if present. If one or more +files are left unspecified, the default names are used as described +below. Following are the subcommands:

privatekey file -: Specifies the directory for the RSA private key file, which -otherwise defaults to /usr/local/etc.; Specifies the location of the RSA private key file, which +otherwise defaults to /usr/local/etc/ntpkey.
publickey file -: Specifies the directory for the RSA public key file, which otherwise -defaults to /usr/local/etc.; Specifies the location of the RSA public key file, which otherwise +defaults to /usr/local/etc/ntpkey_host., where +host is the name of the generating machine.
dhparms file -: Specifies the directory for the Diffie-Hellman parameters file, -which otherwise defaults to /usr/local/etc.; Specifies the location of the Diffie-Hellman parameters file, +which otherwise defaults to /usr/local/etc/ntpkey_dh.

keys keyfile

Specifies the file name containing the private encryption keys and -key identifiers used by ntpd, ntpq and ntpdc -when operating in authenticated mode.

Specifies the location of the DES/MD5 private key file containing +the keys and key identifiers used by ntpd, ntpq and +ntpdc when operating in symmetric-key mode.

keysdir path

This command requires the NTP daemon build process be configured with the RSA library. It specifies the default directory path for the -private key file, parameters file and one or more public key files. The -default when this command does not appear in the configuration file is -/usr/local/etc/.

+private key file, agreement parameters file and one or more public key +files. The default when this command does not appear in the +configuration file is /usr/local/etc/.

requestkey key

Specifies the key identifier to use with the ntpdc utility -program, which uses a proprietary protocol specific to this -implementation of ntpd. This program is useful to diagnose and -repair problems that affect ntpd operation. The -key argument to this command is a key identifier for a -trusted key, where the value can be in the range 1 to 65534, inclusive. -

Specifies the key identifier to use with the ntpdc utility program, which uses a +proprietary protocol specific to this implementation of ntpd. +The key argument is a key identifier for the trusted +key, where the value can be in the range 1 to 65534, inclusive.

revoke [logsec]

Specifies the interval between re-randomization of certain @@ -256,9 +296,9 @@ some values is a relatively expensive operation. The default interval is interval, the values will be updated for every message sent.

trustedkey key [...]

Specifies the encryption key identifiers which are trusted for the -purposes of authenticating peers suitable for synchronization, as well -as keys used by the ntpq and ntpdc programs. The +

Specifies the key identifiers which are trusted for the purposes of +authenticating peers with symmetric-key cryptography, as well as keys +used by the ntpq and ntpdc programs. The authentication procedures require that both the local and remote servers share the same key and key identifier for this purpose, although different keys can be used with different servers. The @@ -272,7 +312,7 @@ from 1 to 65,534.

ntp.keys private MD5 keys
ntpkey RSA private key
ntpkey_host RSA public key -
ntp_dh Diffie-Hellman parameters +
ntp_dh Diffie-Hellman agreement parameters

Bugs

diff --git a/html/ntpq.htm b/html/ntpq.htm index 930886736d..80261a1365 100644 --- a/html/ntpq.htm +++ b/html/ntpq.htm @@ -1,747 +1,276 @@ - - - - - ntpq - standard NTP query program - - - - -

-`pq` - standard NTP query program

- -

-Synopsis

-ntpq [-inp] [-c command] [host] [...] -

-Description

-ntpq is used to query NTP servers which implement the recommended -NTP mode 6 control message format about current state and to request changes -in that state. The program may be run either in interactive mode or controlled -using command line arguments. Requests to read and write arbitrary variables -can be assembled, with raw and pretty-printed output options being available. -ntpq can also obtain and print a list of peers in a common format -by sending multiple queries to the server. - -

If one or more request options is included on the command line when -ntpq is executed, each of the requests will be sent to the NTP -servers running on each of the hosts given as command line arguments, or -on localhost by default. If no request options are given, ntpq -will attempt to read commands from the standard input and execute these -on the NTP server running on the first host given on the command line, -again defaulting to localhost when no other host is specified. ntpq -will prompt for commands if the standard input is a terminal device. - -

ntpq uses NTP mode 6 packets to communicate with the NTP server, -and hence can be used to query any compatable server on the network which -permits it. Note that since NTP is a UDP protocol this communication will -be somewhat unreliable, especially over large distances in terms of network -topology. ntpq makes one attempt to retransmit requests, and will -time requests out if the remote host is not heard from within a suitable + +ntpq - standard NTP query program +

+`ntpq` - standard NTP query program +

+ +

Synopsis

+ +ntpq [-inp] [-c command] [host] [...] + +

Description

+ +The ntpq utility program is used to query NTP servers which implement the recommended NTP mode 6 control message format about current state and to request changes in that state. The program may be run either in interactive mode or controlled using command line arguments. Requests to read and write arbitrary variables can be assembled, with raw and pretty-printed output options being available. ntpq can also obtain and print a list of peers in a common format by sending multiple queries to the server. + +

If one or more request options is included on the command line when ntpq is executed, each of the requests will be sent to the NTP servers running on each of the hosts given as command line arguments, or on localhost by default. If no request options are given, ntpq will attempt to read commands from the standard input and execute these on the NTP server running on the first host given on the command line, again defaulting to localhost when no other host is specified. ntpqwill prompt for commands if the standard input is a terminal device. + +

ntpq uses NTP mode 6 packets to communicate with the NTP server, and hence can be used to query any compatable server on the network which permits it. Note that since NTP is a UDP protocol this communication will be somewhat unreliable, especially over large distances in terms of network topology. ntpq makes one attempt to retransmit requests, and will time requests out if the remote host is not heard from within a suitable timeout time. -

Command line options are described following. Specifying a command line -option other than -i or -n will cause the specified query (queries) to -be sent to the indicated host(s) immediately. Otherwise, ntpq -will attempt to read interactive format commands from the standard input. -

--c: -The following argument is interpreted as an interactive format command -and is added to the list of commands to be executed on the specified host(s). -Multiple -c options may be given.
--i: -Force ntpq to operate in interactive mode. Prompts will be written -to the standard output and commands read from the standard input.
--n: -Output all host addresses in dotted-quad numeric format rather than converting -to the canonical host names.
--p: -Print a list of the peers known to the server as well as a summary of their -state. This is equivalent to the peers interactive command.

- -

-Internal Commands

-Interactive format commands consist of a keyword followed by zero to four -arguments. Only enough characters of the full keyword to uniquely identify -the command need be typed. The output of a command is normally sent to -the standard output, but optionally the output of individual commands may -be sent to a file by appending a "<", followed by a file name, to the -command line. A number of interactive format commands are executed entirely -within the ntpq program itself and do not result in NTP mode 6 -requests being sent to a server. These are described following. -

-? [command_keyword]: -A "?" by itself will print a list of all the command keywords -known to this incarnation of ntpq. A "?" followed by -a command keyword will print funcation and usage information about the -command. This command is probably a better source of information about -ntpq than this manual page.; -
-addvars variable_name [ = value] [...]: -The data carried by NTP mode 6 messages consists of a list of items of -the form variable_name = value, where the " -= value" is ignored, and can be omitted, in requests to the -server to read variables. ntpq maintains an internal list in which -data to be included in control messages can be assembled, and sent using -the readlist and writelist commands described below. The addvars command -allows variables and their optional values to be added to the list. If -more than one variable is to be added, the list should be comma-separated -and not contain white space. The rmvars command can be used to remove individual -variables from the list, while the clearlist command removes all variables -from the list.; -
-authenticate yes | no: -Normally ntpq does not authenticate requests unless they are write -requests. The command authenticate yes causes ntpq to send authentication -with all requests it makes. Authenticated requests causes some servers -to handle requests slightly differently, and can occasionally melt the -CPU in fuzzballs if you turn authentication on before doing a peer display.; -
-cooked: -Causes output from query commands to be "cooked". Variables which -are recognized by the server will have their values reformatted for human -consumption. Variables which ntpq thinks should have a decodeable -value but didn't are marked with a trailing "?".; -
-debug more | less | off: -Turns internal query program debugging on and off.; -
-delay milliseconds: -Specify a time interval to be added to timestamps included in requests -which require authentication. This is used to enable (unreliable) server -reconfiguration over long delay network paths or between machines whose -clocks are unsynchronized. Actually the server does not now require timestamps -in authenticated requests, so this command may be obsolete.; -
-host hostname: -Set the host to which future queries will be sent. Hostname may be either -a host name or a numeric address.; -
-hostnames [yes | no]: -If "yes" is specified, host names are printed in information displays. -If "no" is specified, numeric addresses are printed instead. The -default is "yes", unless modified using the command line -n -switch.; -
-keyid keyid: -This command allows the specification of a key number to be used to authenticate -configuration requests. This must correspond to a key number the server -has been configured to use for this purpose.; -
-ntpversion 1 | 2 | 3 | 4: -Sets the NTP version number which ntpq claims in packets. Defaults -to 3, Note that mode 6 control messages (and modes, for that matter) didn't -exist in NTP version 1. There appear to be no servers left which demand -version 1.; -
-quit: -Exit ntpq.; -
-passwd: -This command prompts you to type in a password (which will not be echoed) -which will be used to authenticate configuration requests. The password -must correspond to the key configured for use by the NTP server for this -purpose if such requests are to be successful.; -
-raw: -Causes all output from query commands is printed as received from the remote -server. The only formating/intepretation done on the data is to transform -nonascii data into a printable (but barely understandable) form.; -
-timeout millseconds: -Specify a timeout period for responses to server queries. The default is -about 5000 milliseconds. Note that since ntpq retries each query -once after a timeout, the total waiting time for a timeout will be twice -the timeout value set.

- -

-Control Message Commands

-Each peer known to an NTP server has a 16 bit integer association identifier -assigned to it. NTP control messages which carry peer variables must identify -the peer the values correspond to by including its association ID. An association -ID of 0 is special, and indicates the variables are system variables, whose -names are drawn from a separate name space. - -

Control message commands result in one or more NTP mode 6 messages being -sent to the server, and cause the data returned to be printed in some format. -Most commands currently implemented send a single message and expect a -single response. The current exceptions are the peers command, which will -send a preprogrammed series of messages to obtain the data it needs, and -the mreadlist and mreadvar commands, which will iterate over a range of -associations. -

-associations: -Obtains and prints a list of association identifiers and peer statuses -for in-spec peers of the server being queried. The list is printed in columns. -The first of these is an index numbering the associations from 1 for internal -use, the second the actual association identifier returned by the server -and the third the status word for the peer. This is followed by a number -of columns containing data decoded from the status word See the peers command -for a decode of the condition field. Note that the data returned -by the "associations" command is cached internally in ntpq. -The index is then of use when dealing with stupid servers which use association -identifiers which are hard for humans to type, in that for any subsequent -commands which require an association identifier as an argument, the form -and index may be used as an alternative.; -
-clockvar [assocID] [variable_name [ = value [...] -] [...]
-cv [assocID] [variable_name [ = value [...] ] -[...]: -Requests that a list of the server's clock variables be sent. Servers which -have a radio clock or other external synchronization will respond positively -to this. If the association identifier is omitted or zero the request is -for the variables of the "system clock" and will generally get -a positive response from all servers with a clock. If the server treats -clocks as pseudo-peers, and hence can possibly have more than one clock -connected at once, referencing the appropriate peer association ID will -show the variables of a particular clock. Omitting the variable list will -cause the server to return a default variable display.; -
-lassocations: -Obtains and prints a list of association identifiers and peer statuses -for all associations for which the server is maintaining state. This command -differs from the "associations" command only for servers which -retain state for out-of-spec client associations (i.e., fuzzballs). Such -associations are normally omitted from the display when the "associations" -command is used, but are included in the output of "lassociations".; -
-lpassociations: -Print data for all associations, including out-of-spec client associations, -from the internally cached list of associations. This command differs from -"passociations" only when dealing with fuzzballs.; -
-lpeers: -Like R peers, except a summary of all associations for which the server -is maintaining state is printed. This can produce a much longer list of -peers from fuzzball servers.; -
-mreadlist assocID assocID: -Like the readlist command, except the query is done for each of -a range of (nonzero) association IDs. This range is determined from the -association list cached by the most recent associations command.; -
-mreadvar assocID assocID [ variable_name [ = value -[ ... ]: -Like the readvar command, except the query is done for each of -a range of (nonzero) association IDs. This range is determined from the -association list cached by the most recent associations command.; -
-opeers: -An old form of the peers command with the reference ID replaced -by the local interface address.; -
-passociations: -Prints association data concerning in-spec peers from the internally cached -list of associations. This command performs identically to the "associations" -except that it displays the internally stored data rather than making a -new query.; -
-peers: -Obtains a current list peers of the server, along with a summary of each -peer's state. Summary information includes the address of the remote peer, -the reference ID (0.0.0.0 if this is unknown), the stratum of the remote -peer, the type of the peer (local, unicast, multicast or broadcast), when -the last packet was received, the polling interval, in seconds, the reachability -register, in octal, and the current estimated delay, offset and dispersion -of the peer, all in milliseconds.; -TEST1; -TEST2; -TEST3; -TEST4; -The following TEST5 through TEST10 ennumerate errors -in the packet header. The packet is discarded without inspecting its contents.; -TEST5; -TEST6; -TEST7; -TEST8; -TEST9; -TEST10
-pstatus assocID: -Sends a read status request to the server for the given association. The -names and values of the peer variables returned will be printed. Note that -the status word from the header is displayed preceding the variables, both -in hexidecimal and in pidgeon English.; -
-readlist [ assocID ]: -Requests that the values of the variables in the internal variable list -be returned by the server. If the association ID is omitted or is 0 the -variables are assumed to be system variables. Otherwise they are treated -as peer variables. If the internal variable list is empty a request is -sent without data, which should induce the remote server to return a default -display.; -
-readvar assocID variable_name [ = value ] [ ... -]: -Requests that the values of the specified variables be returned by the -server by sending a read variables request. If the association ID is omitted -or is given as zero the variables are system variables, otherwise they -are peer variables and the values returned will be those of the corresponding -peer. Omitting the variable list will send a request with no data which -should induce the server to return a default display.; -
-writevar assocID variable_name [ = value [ ... -]: -Like the readvar request, except the specified variables are written instead -of read.; -
-writelist [ assocID ]: -Like the readlist request, except the internal list variables are written -instead of read.

- -

-Bugs

The peers command is non-atomic and may occasionally result in spurious error messages about invalid associations occurring and terminating the -command. The timeout time is a fixed constant, which means you wait a long -time for timeouts since it assumes sort of a worst case. The program should -improve the timeout estimate as it sends queries to a particular host, -but doesn't. -

-David L. Mills (mills@udel.edu)

- - - +command. The timeout time is a fixed constant, which means you wait a long time for timeouts since it assumes sort of a worst case. The program should improve the timeout estimate as it sends queries to a particular host, but doesn't. + +

David L. Mills <mills@udel.edu> +

diff --git a/html/release.htm b/html/release.htm index 40ca08966e..7f31b38b17 100644 --- a/html/release.htm +++ b/html/release.htm @@ -15,11 +15,12 @@ new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions. The NTPv4 version has been under development for quite a while and isn't finished yet. In fact, quite a number of NTPv4 -features have already been implemented in the current NTPv3. The primary -purpose of this release is to verify the remaining new code compiles and -runs in the various architectures, operating systems and hardware -complement that can't be verified here. Of particular interest are -Windows NT, VMS and various reference clock drivers. As always, +features have already been retrofitted in the current NTPv3, although +this version is not actively maintained by the NTPv4 developer's group. +The primary purpose of this release is to verify the remaining new code +compiles and runs in the various architectures, operating systems and +hardware complement that can't be verified here. Of particular interest +are Windows 2000, VMS and various reference clock drivers. As always, corrections and bugfixes are warmly received, especially in the form of context diffs. @@ -139,7 +140,7 @@ Options page for details.

The scheme for enabling the ppsclock line discipline/streams module has changed. Formerly, it was enabled by -setting ffudge flag3 for the serial port connected to the PPS +setting fudge flag3 for the serial port connected to the PPS signal. Now, there is an explicit command pps used to designate the device name. See the Reference Clock Options page for details.

@@ -154,35 +155,62 @@ should precede these commands.

Caveats

This release has been compiled and tested on several systems, including -SunOS 4.1.3, Solaris 2.5.1 and 2.7, Alpha 4.0, Ultrix 4.4, Linux, -FreeBSD 3.4 and HP-UX 10.02. It has not been compiled for Windows NT or -VMS. We are relying on the NTP volunteer brigade to do that. Known -problems are summarized below: +SunOS 4.1.3, Solaris 2.5.1-2.8, Alpha 4.0, Ultrix 4.4, Linux, FreeBSD +3.4 and HP-UX 10.02. It has been compiled and tested on Windows NT, but +not yet on any other Windows version or for VMS. We are relying on the +NTP volunteer corps to do that. Known problems are summarized below:

The latest NTPv4 ntpdc does not work with previous versions of ntpd and previous versions of ntpdc do not work with latest ntpd. This situation is regrettable and may be fixed in future; however, it is necessary in order for the autokey function to retrieve canonical names and certificates from directory services such as Secure DNS. +
The latest NTPv4 ntpdc does not work with previous +versions of ntpd and previous versions of ntpdc do not +work with latest ntpd. This situation is regrettable and may be +fixed in future; however, it is necessary in order for the autokey +function to retrieve canonical names and certificates from directory +services such as Secure DNS.
To work properly in all cases, the enable and pps commands, if used, should appear before the server and fudge commands in the configuration file.

The precision time kernel modifications formerly in stock Solaris -2.6 have bugs that were fixed in 2.7. A patch is available that fixes -the 2.6 bugs. The 2.6 kernel discipline has been disabled by default. -For testing, the kernel can be enabled using the enable kernel -command either in the configuration file or via ntpdc.

The latest release of NTP4 includes support for tne nanokernel +precision time kernel support, which is now in stock Linux and FreeBSD +kernels. If a precision time source such as a GPS timing receiver or +cesium clock is available, kernel timekeeping can be improved to the +order less than one microsecond. The older precision time kernel for the +Alpha continues to be supported. The precision time support in stock +Solaris 2.6 has bugs that were fixed in 2.7. A patch is available that +fixes the 2.6 bugs. The 2.6 kernel discipline has been disabled by +default. For testing, the kernel can be enabled using the enable +kernel command either in the configuration file or via +ntpdc.

A new pulse-per-second (PPS) generic interface described in Mogul, J., D. Mills, J. +Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like +operating systems, version 1. Request for Comments RFC-2783, Internet +Engineering Task Force, March 2000, 31 pp is supported. Older +interfaces and line disciplines continue to be supported, but may be +withdrawen in future versions.
On Alpha 4.0 with reference clocks configured, debugging with the -d options doesn't work.

The autokey function uses NTP header extensions fields, -which is documented in an Internet Draft and implemented in this -release. At present the keys and related cryptographic data are stored -in the form of files generated by the ntp_genkeys program. It is expected that in future -these values will be obtained automatically from the Secure DNS -following deployment.

The latest release of NTPv4 includes support for autokey +public-key cryptography, which is the preferred scheme for +authenticating servers to clients. It uses NTP header extensions fields +documented in Mills, D.L. Public key +cryptography for the Network Time Protocol. Electrical Engineering +Report 00-5-1, University of Delaware, May 2000. 23 pp and +implemented in this release. However, the protocol is still evolving and +some fields may not conform to that document. The design provides for +orderly key refreshment and does not require public keys and related +media to be copied from one machine to another. Specific information +about autokey cryptography is contained in the Authentication Options page and links from +thnere.

The manycast function still needs some work. Ideally, the existing I/O routines would be enhanced to include the capability to

Public-Key Scheme

Key Management

Authentication Commands

Bugs

-pq - standard NTP query program

-Synopsis

-Description

+ntpq - standard NTP query program +

Synopsis

Description

-Internal Commands

-Control Message Commands

Internal Commands

Control Message Commands

Bugs

-Bugs

Caveats

-`pq` - standard NTP query program

+`ntpq` - standard NTP query program +