From: Harlan Stenn Date: Mon, 3 Feb 2003 05:32:41 +0000 (-0500) Subject: Cleanup from Dave Mills. X-Git-Tag: NTP_4_1_74~17 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=453ce6e41bcb79f5dc6e0fe0efa4e0c118493726;p=thirdparty%2Fntp.git Cleanup from Dave Mills. bk: 3e3dfef99_c1xv1Xzn-4OyiXPxnICQ --- diff --git a/html/clockopt.html b/html/clockopt.html index eab01906cb..129e9fb942 100644 --- a/html/clockopt.html +++ b/html/clockopt.html @@ -10,9 +10,9 @@

Reference Clock Options

from Pogo, Walt Kelly + gif

See the radios, all in a row.

Last update: 20:36 UTC Monday, December 02, 2002

Last update: 15:48 UTC Sunday, February 02, 2003

Copyright Notice

"Clone me," says Dolly sheepishly -

Last update: 20:31 UTC Monday, December 02, 2002

Last update: 15:44 UTC Sunday, February 02, 2003

The following copyright notice applies to all files collectively called the Network Time Protocol Version 4 Distribution. Unless specifically declared otherwise in an individual file, this notice applies as if the text was explicitly included in the file.
@@ -18,7 +18,7 @@

 ***********************************************************************
 *                                                                     *
-* Copyright (c) David L. Mills 1992-2002                              *
+* Copyright (c) David L. Mills 1992-2003                              *
 *                                                                     *
 * Permission to use, copy, modify, and distribute this software and   *
 * its documentation for any purpose and without fee is hereby         *
diff --git a/html/debug.html b/html/debug.html
index 0d85c795b0..303e3175b9 100644
--- a/html/debug.html
+++ b/html/debug.html
@@ -12,7 +12,7 @@
         NTP Debugging Techniques
         from Pogo, Walt Kelly
         We make house calls and bring our own bugs.
-        Last update: 21:30 UTC Sunday, January 26, 2003
+        Last update: 15:34 UTC Sunday, February 02, 2003
         

         More Help
         
@@ -20,14 +20,14 @@
         Once the NTP software distribution has been compiled and installed and the configuration file constructed, the next step is to verify correct operation and fix any bugs that may result. Usually, the command line that starts the daemon is included in the system startup file, so it is executed only at system boot time; however, the daemon can be stopped and restarted from root at any time. Usually, no command-line arguments are required, unless special actions described in the ntpd - Network Time Protocol (NTP) daemon page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.
         Initial Startup
         When started for the first time, the frequency file, usually called ntp.drift, has not yet been created. The daemon switches to a special training routine designed to quickly determine the system clock frequency offset of the particular machine. The routine first measures the current clock offset and sets the clock, then continues for up to twenty minutes before measuring the clock offset, which might involve setting the clock again. The two measurements are used to compute the initial frequency offset and the daemon continues in regular operation, during which the frequency offset is continuously updated. Once each hour the daemon writes the current frequency offset to the ntp.drift file. When restarted after that, the daemon reads the frequency offset from the ntp.drift file and avoids the training routine.
-        Note that the daemon requires at least four packet exchanges when first started in any case. This is required in order for the mitigation algorithms to insure valid and accurate measurements and defend against network delay spikes and accidental or malicious errors induced by the servers selected in the configuration file. It normally takes less than four minutes to set the clock when first started, but this can be reduced to less than  ten seconds with the iburst configuration option. 
+        Note that the daemon requires at least four packet exchanges when first started in any case. This is required in order for the mitigation algorithms to insure valid and accurate measurements and defend against network delay spikes and accidental or malicious errors induced by the servers selected in the configuration file. It normally takes less than four minutes to set the clock when first started, but this can be reduced to less than ten seconds with the iburst configuration option.
         The best way to verify correct operation is using the ntpq - standard NTP query program and ntpdc - special NTP query program utility programs, either on the server itself or from another machine elsewhere in the network. The ntpq program implements the management functions specified in the NTP specification RFC-1305, Appendix A. The ntpdc program implements additional functions not provided in the standard. Both programs can be used to inspect the state variables defined in the specification and, in the case of ntpdc, additional ones intended for serious debugging. In addition, the ntpdc program can be used to selectively reconfigure and enable or disable some functions while the daemon is running.
         In extreme cases with elusive bugs, the daemon can operate in two modes, depending on the presence of the -d command-line debug switch. If not present, the daemon detaches from the controlling terminal and proceeds autonomously. If one or more -d switches are present, the daemon does not detach and generates special output useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single -d does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles. With a little experience, the volume of output can be reduced by piping the output to grep and specifying the keyword of the trace you want to see.
         Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix /etc/services file (or equivalent in some systems). Note that NTP does not use TCP in any form. Also note that NTP requires 123 for both source and destination ports. These facts should be pointed out to firewall administrators.
-        Other problems are apparent in the system log, which ordinarily shows the startup banner, some cryptic initialization data and the computed precision value. Error messages at startup and during regular operation are sent to the system log. In real emergencies the daemon will sent a terminal error message to the system log and  then cease operation.
+        Other problems are apparent in the system log, which ordinarily shows the startup banner, some cryptic initialization data and the computed precision value. Error messages at startup and during regular operation are sent to the system log. In real emergencies the daemon will sent a terminal error message to the system log and then cease operation.
         The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the Unix ping command. The Unix traceroute or Windows tracert utility can be used to verify a partial or complete path exists. Most problems reported to the NTP newsgroup are not NTP problems, but problems with the network or firewall configuration.
         When first started, the daemon polls the servers listed in the configuration file at 64-s intervals. In order to allow a sufficient number of samples for the NTP algorithms to reliably discriminate between truechimer servers and possible falsetickers, at least four valid messages from at least one server or peer listed in the configuration file is required before the daemon can set the clock. However, if the difference between the client time and server time is greater than the panic threshold, which defaults to 1000 s, the daemon sends a message to the system log and shuts down without setting the clock. It is necessary to set the local clock to within the panic threshold first, either manually by eyeball and wristwatch and the Unix date command, or by the ntpdate or ntpd -q commands. The panic threshold can be changed by the tinker panic command discribed on the Miscellaneous Options page. The panic threshold can be disabled for the first measurement by the -g command line option described on the ntpd - Network Time Protocol (NTP) daemon page.
-        If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. Step adjustments are extremely rare in ordinary operation, usually as the result of reboot or hardware failure. The step threshold can be changed to 300 s using the -x command line option described on the ntpd page. This is usually sufficient to avoid a step after reboot or when the operator has set the system clock to within five minutes by eyeball-and-wristwatch. In extreme cases the step threshold can be changed by the tinker step command discribed on the Miscellaneous Options page. If set to zero, the clock will never be stepped; however, users should understand the implications for doing this in a distributed data network where all processing must be tightly synchronized. See the NTP Timescale and Leap Seconds page for further information. If a step adjustment is made, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.
+        If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 128 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. Step adjustments are extremely rare in ordinary operation, usually as the result of reboot or hardware failure. The step threshold can be changed to 300 s using the -x command line option described on the ntpd page. This is usually sufficient to avoid a step after reboot or when the operator has set the system clock to within five minutes by eyeball-and-wristwatch. In extreme cases the step threshold can be changed by the tinker step command discribed on the Miscellaneous Options page. If set to zero, the clock will never be stepped; however, users should understand the implications for doing this in a distributed data network where all processing must be tightly synchronized. See the NTP Timescale and Leap Seconds page for further information. If a step adjustment is made, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.
         The clock discipline algorithm is designed to avoid large noise spikes that might occur on a congested network or access line. If an offset sample exceeds the step threshold, it is ignored and a timer started. If a later sample is below the step threshold, the counter is reset and operation continues normally. However, if the counter is greater than the stepout interval, which defaults to 900 s, the next sample will step the time as directed. The stepout threshold can be changed by the tinker stepout command discribed on the Miscellaneous Options page.
         If for some reason the hardware clock oscillator frequency error is very large, say over 400 PPM, the time offset when the daemon is started for the first time may increase over time until exceeding the step threshold, which requires a frequency adjustment and another step correction. However, due to provisions that reduce vulnerability to noise spikes, the second correction will not be done until after the stepout threshold. When the frequency error is very large, it may take a number of cycles like this until converging to the nominal frequency correction and writing the ntp.drift file. If the frequency error is over 500 PPM, convergence will never occur and occasional step adjustments will occur indefinitely.
         Verifying Correct Operation
@@ -42,10 +42,10 @@ ntpq> pe
 *pogo.udel.edu   .GPS1.        1 u  95 128  377   0.607  0.123  0.027

The host names or addresses shown in the remote column correspond to the server and peer entries listed in the configuration file; however, the DNS names might not agree if the names listed are not the canonical DNS names. IPv4 addresses are shown in dotted quad notation, while IPv6 addresses are shown alarmingly. The refid column shows the current source of synchronization, while the st column reveals the stratum, t the type (u = unicast, m = multicast, l = local, - = don't know), and poll the poll interval in seconds. The when column shows the time since the peer was last heard in seconds, while the reach column shows the status of the reachability register (see RFC-1305) in octal. The remaining entries show the latest delay, offset and jitter in milliseconds. Note that in NTP Version 4 what used to be the dispersion column has been replaced by the jitter column.

As per the NTP specification RFC-1305, when the stratum is between 0 and 15 for a NTP server, the refid field shows the server DNS name or, if not found, the IP address in dotted-quad. When the stratum is any value for a reference clock, this field shows the identification string assigned to the clock. However, until the client has synchronized to a server, or when the stratum for a NTP server is 0 (appears as 16 in the billboards), the status cannot be determined. As a help in debugging, the refid field is set as follows.

Peer Variables

Peer Kiss Codes

ACST

ACST: The association belongs to a anycast server.
AUTH: Server authentication failed. Please wait while the association is restarted. @@ -74,14 +74,14 @@ ntpq> pe
STEP: A step change in system time has occured, but the association has not yet resynchronized.

System Variables

System Kiss Codes

INIT: The system clock has not yet synchronized for the first time.
STEP: A step change in system time has occured, but the system clock has not yet resynchronized.

The tattletale symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked *, while additional peers designated acceptable for synchronization, but not currently selected, are marked +. Peers marked * and + are included in the weighted average computation to set the local clock; the data produced by peers marked with other symbols are discarded. See the ntpq page for the meaning of these symbols.

The tattletale symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked *, while additional peers designated acceptable for synchronization are marked +. Peers marked * and + are included in the weighted average computation to set the local clock; the data produced by peers marked with other symbols are discarded. See the ntpq page for the meaning of these symbols.

Additional details for each peer separately can be determined by the following procedure. First, use the as command to display an index of association identifiers, such as

 ntpq> as
@@ -134,7 +134,7 @@ cert="whimsy.udel.edu whimsy.udel.edu 0x5 3233682156"
         An explanation about most of these variables is in the RFC-1305 specification. The most useful ones include clock, which shows when the clock was last adjusted, and reftime, which shows when the server clock of refid was last adjusted. The version, processor and system values are very helpful when included in bug reports. The mean millisecond time offset (phase) and deviation (jitter) monitor the clock quality, while the mean PPM frequency offset (frequency) and deviation (stability) monitor the clock stability and serve as a useful diagnostic tool. It has been the experience of NTP operators over the years that these data represent useful environment and hardware alarms. If the motherboard fan freezes up or some hardware bit sticks, the system clock is usually the first to notice it.
         Among the new variables added for NTP Version 4 are the hostname, signature, flags, hostkey, refresh and cert, which are used for the Autokey public-key cryptography described on the Authentication Options page. The numeric values show the filestamps, in NTP seconds, that the associated media files were created. These are useful in diagnosing problems with cryptographic key consistency and ordering principles.
         When nothing seems to happen in the pe billboard after some minutes, there may be a network problem. One common network problem is an access controlled router on the path to the selected peer or an access controlled server using methods described on the Access Control Options page. Another common problem is that the server is down or running in unsynchronized mode due to a local problem. Use the ntpq program to spy on the server variables in the same way you can spy on your own.
-        Normally, the daemon will adjust the local clock in small steps in such a way that system and user programs are unaware of its operation. The adjustment process operates continuously as long as the apparent clock error exceeds the step threshold for a period longer than the stepout threshold, which for most Internet paths is a very rare event. If the event is simply an outlyer due to an occasional network delay spike, the correction is simply discarded; however, if the apparent time error persists for longer than the stepout threshold of about 17 minutes, the local clock is stepped or slewed to the new value as directed. This behavior is designed to resist errors due to severely congested network paths, as well as errors due to confused radio clocks upon the epoch of a leap second.
+        Normally, the daemon will adjust the local clock in small steps in such a way that system and user programs are unaware of its operation. The adjustment process operates continuously unless the apparent clock error exceeds the step threshold for a period longer than the stepout threshold, which for most Internet paths is a very rare event. If the event is simply an outlyer due to an occasional network delay spike, the correction is simply discarded; however, if the apparent time error persists for longer than the stepout threshold of about 17 minutes, the local clock is stepped or slewed to the new value as directed. This behavior is designed to resist errors due to severely congested network paths, as well as errors due to confused radio clocks upon the epoch of a leap second.
         Large Frequency Errors
         The frequency tolerance of computer clock oscillators can vary widely, which can put a strain on the daemon's ability to compensate for the intrinsic frequency error. While the daemon can handle frequency errors up to 500 parts-per-million (PPM), or 43 seconds per day, values much above 100 PPM reduce the headroom and increase the time to learn the particular value and record it in the ntp.drift file. In extreme cases before the particular oscillator frequency error has been determined, the residual system time offsets can sweep from one extreme to the other of the 128-ms tracking window only for the behavior to repeat at 900-s intervals until the measurements have converged.
         In order to determine if excessive frequency error is a problem, observe the nominal filtoffset values for a number of rounds and divide by the poll interval. If the result is something approaching 500 PPM, there is a good chance that NTP will not work properly until the frequency error is reduced by some means. A common cause is the hardware time-of-year (TOY) clock chip, which must be disabled when NTP disciplines the software clock. For some systems this can be done using the tickadj utility and the -s command line argument. For other systems this can be done using a command in the system startup file.
@@ -149,18 +149,19 @@ cert="whimsy.udel.edu whimsy.udel.edu 0x5 3233682156"
         Reliable source authentication requires the use of symmetric key or public key cryptography, as described on the Authentication Options page. In symmetric key cryptography servers and clients share session keys contained in a secret key file In public key cryptography, which requires the OpenSSL software library, the server has a private key, never shared, and a public key with unrestricted distribution. The cryptographic media required are produced by the ntp-keygen program.
         Problems with symmetric key authentication are usually due to mismatched keys or improper use of the trustedkey command. A simple way to check for problems is to use the trace facility, which is enabled using the ntpd -d command line. As each packet is received a trace line is displayed which shows the authentication status in the auth field. A status of 1 indicates the packet was successful authenticated; otherwise it has failed.
         A common misconception is the implication of the auth bit in the enable and disable commands. This bit does not affect authentication in any way other than to enable or disable mobilization of a new persistent association in broadcast/multicast client, manycast client or symmetric passive modes. If enabled, which is the default, these associations require authentication; if not, an association is mobilized even if not authenticated. Users are cautioned that running with authentication disabled is very dangerous, since an intruder can easily strike up an association and inject false time values.
-        Public key cryptography is supported in NTPv4 using the Autokey protocol, which is described in briefings on the NTP Project page linked from www.ntp.org. Development of this protocol is mature and the ntpd implementation is basically complete. Autokey version 2, which is the latest and current version, includes provisions to walk certificate trails, operate as certificate authorities and verify identity using challenge/response identification schemes. Further details of the protocol are on the Authentication Options page. Common problems with configuration and key generation are mismatched key files, broken links and missing or broken random seed file.
+        Public key cryptography is supported in NTPv4 using the Autokey protocol, which is described in briefings on the NTP Project page linked from www.ntp.org. Development of this protocol is mature and the ntpd implementation is basically complete. Autokey version 2, which is the latest and current version, includes provisions to hike certificate trails, operate as certificate authorities and verify identity using challenge/response identification schemes. Further details of the protocol are on the Authentication Options page. Common problems with configuration and key generation are mismatched key files, broken links and missing or broken random seed file.
         As in the symmetric key cryptography case, the trace facility is a good way to verify correct operation. A statistics file cryptostats records protocol transactions and error messages. The daemon requires a random seed file, public/private key file and a valid certificate file; otherwise it exits immediately with a message to the system log. As each file is loaded a trace message appears with its filestamp. There are a number of checks to insure that only consistent data are used and that the certificate is valid. When the protocol is in operation a number of checks are done to verify the server has the expected credentials and its filestamps and timestamps are consistent. Errors found are reported using NTP control and monitoring protocol traps with extended trap codes shown in the Authentication Options page.
         To assist debugging every NTP extension field is displayed in the trace along with the Autokey operation code. Every extension field carrying a verified signature is identified and displayed along with filestamp and timestamp where meaningful. In all except broadcast/multicast client mode, correct operation of the protocol is confirmed by the absence of extension fields and an auth value of one. It is normal in broadcast/multicast client mode that the broadcast server use one extension field to show the host name, status word and association ID.
         Debugging Checklist
         If the ntpq or ntpdc programs do not show that messages are being received by the daemon or that received messages do not result in correct synchronization, verify the following:
         
             Verify the /etc/services file host machine is configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use UDP and does not respond to TCP.
-            
Check the system log for ntpd messages about configuration errors, name-lookup failures or initialization problems. Check to be sure that only one copy of ntpd is running.
+            
Check the system log for ntpd messages about configuration errors, name-lookup failures or initialization problems. Common system log messages are summarized on the ntpd System Log Messages page. Check to be sure that only one copy of ntpd is running.
             
Verify using ping or other utility that packets actually do make the round trip between the client and server. Verify using nslookup or other utility that the DNS server names do exist and resolve to valid Internet addresses.
+
+            
Check that the remote NTP server is up and running. The usual evidence that it is not is a Connection refused message.
             
Using the ntpdc program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something may be wrong in the host network or interface configuration. If this counter does increment, but the received counter does not increment, something may be wrong in the network or the server NTP daemon may not be running or the server itself may be down or not responding.
-            
If both the sent and received counters do increment, but the reach values in the pe billboard with ntpq continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the flash variable as discussed above and on the ntpq page.
-            
If the reach values in the pe billboard show the servers are alive and responding, note the tattletale symbols at the left margin, which indicate the status of each server resulting from the various grooming and mitigation algorithms. The interpretation of these symbols is discussed on the ntpq page. After a few minutes of operation, one or another of the reachable server candidates should show a * tattletale symbol. If this doesn't happen, the intersection algorithm, which classifies the servers as truechimers or falsetickers, may be unable to find a majority of truechimers among the server population.
+            
If both the sent and received counters do increment, but the reach values in the pe billboard with ntpq continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the flash variable as discussed above and on the ntpq page. It could be that the server has disabled access for the client address, in which case the refid field in the ntpq pe billboard will show a kiss code. See earlier on this page for a list of kiss codes and their meaning.            
If the reach values in the pe billboard show the servers are alive and responding, note the tattletale symbols at the left margin, which indicate the status of each server resulting from the various grooming and mitigation algorithms. The interpretation of these symbols is discussed on the ntpq page. After a few minutes of operation, one or another of the reachable server candidates should show a * tattletale symbol. If this doesn't happen, the intersection algorithm, which classifies the servers as truechimers or falsetickers, may be unable to find a majority of truechimers among the server population.
             
If all else fails, see the FAQ and/or the discussion and briefings at the NTP Project page.
         
         
diff --git a/html/extern.html b/html/extern.html
index 4c5a11e966..89a1b56d02 100644
--- a/html/extern.html
+++ b/html/extern.html
@@ -10,17 +10,21 @@
 
     
         External Clock Discipline and the Local Clock Driver
-        Last update: 14:44 UTC Monday, January 20, 2003
+        Last update: 15:41 UTC Sunday, February 02, 2003
         
-        The NTPv4 implementation includes provisions for an external clock, where the system clock is implemented by some external hardware device. One implementation might take the form of a bus peripheral with a high resolution counter disciplined by a GPS receiver, for example. Another implementation might involve another synchronization protocol, such as the Digital Time Synchronization Service (DTSS), where the system time is disciplined to this protocol and NTP clients of the server obtain synchronization indirectly via the server. A third implementation might be a completely separate clock discipline algorithm and synchronization protocol, such as the Lockclock algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.
+        The NTPv4 implementation includes provisions for an external clock, where the system clock is implemented by some external hardware device. One implementation might take the form of a bus peripheral with a high resolution counter disciplined by a GPS receiver, for example. Another implementation might involve another synchronization protocol, such as the Digital Time Synchronization Service (DTSS), where the system time is disciplined to this protocol and NTP clients of the server obtain synchronization indirectly via the server. A third implementation might be a completely separate clock discipline algorithm and synchronization protocol, such as the Lockclock algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.
         When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon ntpd to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail and synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.
         Control and monitoring functions for the external clock and driver are implemented using the Local Clock (type 1) driver and the ntp_adjtime() system call. This system call is implemented by special kernel provisions included in the kernel of several operating systems, including Solaris, Tru64, FreeBSD and Linux, and possibly others. When the external clock is disabled or not implemented, the system call is used to pass time and frequency information, as well as error statistics, to the kernel. Besides disciplining the system time, the same interface can be used by other applications to determine the operating parameters of the discipline.
         When the external clock is enabled, ntpd does not discipline the system clock, nor does it maintain the error statistics. In this case, the external clock and driver do this using mechanisms unknown to ntpd; however, in this case the kernel state variables are retrieved at 64-s intervals by the Local Clock driver and used by the clock selection and mitigation algorithms to determine the system variables presented to other NTP clients and peers. In this way, downstream clients and servers in the NTP subnet can make an intelligent choice when more than one server is available.
         In order to implement a reliable mitigation between ordinary NTP sources and the external clock source, a protocol is necessary between the local clock driver and the external clock driver. This is implemented using Boolean variables and certain bits in the kernel clock status word. The Boolean variables include the following:
-        ntp__enable. set/reset by enable command. enables ntp clock discipline
-        ntp_control. set during initial configuration if kernel support is available kern_enable Set/reset by enable commandexit If this switch is set, the daemon computes the offset, frequency, maximum error, estimated error, time constand and status bits, then provides them to the kernel via ntp_adjtime(). If this switch is set, these values are not passed to the kernel; however, the daemon retrieves their present values and uses them in place of the values computed by the daemon. pps_update set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero. pps_control Updated to the current time by kernel support if the PPS signal is enabled and working correctly. Set to zero in the adjust routine if the interval since the last update exceeds 120 s.
-        The ntp_enable and kern_enable are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The pps_update switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The ntp_control switch is set during configuration by interrogating the kernel. If both the kern_enable and ntp_control siwitches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.
-        The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the ntp_adjtime() system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero.
+        ntp_enable. set/reset by the enable command. enables ntp clock discipline
+        ntp_control. set during initial configuration if kernel support is available
+        kern_enable Set/reset by the enable command
+        If the kern_enable switch is set, the daemon computes the offset, frequency, maximum error, estimated error, time constand and status bits, then provides them to the kernel via ntp_adjtime(). If this switch is not set, these values are not passed to the kernel; however, the daemon retrieves their present values and uses them in place of the values computed by the daemon.
+        The pps_update bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.
+        The pps_control Updated to the current time by kernel support if the PPS signal is enabled and working correctly. Set to zero in the adjust routine if the interval since the last update exceeds 120 s.
+        The ntp_enable and kern_enable are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The pps_update switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The ntp_control switch is set during configuration by interrogating the kernel. If both the kern_enable and ntp_control switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.
+        The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the ntp_adjtime() system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero.
         
         
     
diff --git a/ntpd/ntp_crypto.c b/ntpd/ntp_crypto.c
index 66d7282b1b..a4f1cc2b74 100644
--- a/ntpd/ntp_crypto.c
+++ b/ntpd/ntp_crypto.c
@@ -1632,10 +1632,11 @@ crypto_ident(
 	/*
 	 * If the server identity has already been verified, no further
 	 * action is necessary. Otherwise, try to load the identity file
-	 * containing the scheme parameters. If the file does not exist,
-	 * not to worry. Note we can't get here unless the trusted
-	 * certificate has been found and the CRYPTO_FLAG_VALID bit is
-	 * set, so the certificate issuer is valid.
+	 * of the certificate issuer. If the issuer file is not found,
+	 * try the host file. If nothing found, declare a cryptobust.
+	 * Note we can't get here unless the trusted certificate has
+	 * been found and the CRYPTO_FLAG_VALID bit is set, so the
+	 * certificate issuer is valid.
 	 */
 	if (peer->crypto & CRYPTO_FLAG_VRFY)
 		return (0);
@@ -1648,6 +1649,12 @@ crypto_ident(
 		peer->ident_pkey = crypto_key(filename, &peer->fstamp);
 		if (peer->ident_pkey != NULL)
 			return (CRYPTO_GQ);
+
+		snprintf(filename, MAXFILENAME, "ntpkey_gq_%s",
+		    sys_hostname);
+		peer->ident_pkey = crypto_key(filename, &peer->fstamp);
+		if (peer->ident_pkey != NULL)
+			return (CRYPTO_GQ);
 	}
 	if (peer->crypto & CRYPTO_FLAG_IFF) {
 		snprintf(filename, MAXFILENAME, "ntpkey_iff_%s",
@@ -1655,6 +1662,12 @@ crypto_ident(
 		peer->ident_pkey = crypto_key(filename, &peer->fstamp);
 		if (peer->ident_pkey != NULL)
 			return (CRYPTO_IFF);
+
+		snprintf(filename, MAXFILENAME, "ntpkey_iff_%s",
+		    sys_hostname);
+		peer->ident_pkey = crypto_key(filename, &peer->fstamp);
+		if (peer->ident_pkey != NULL)
+			return (CRYPTO_IFF);
 	}
 	if (peer->crypto & CRYPTO_FLAG_MV) {
 		snprintf(filename, MAXFILENAME, "ntpkey_mv_%s",
@@ -1662,6 +1675,12 @@ crypto_ident(
 		peer->ident_pkey = crypto_key(filename, &peer->fstamp);
 		if (peer->ident_pkey != NULL)
 			return (CRYPTO_MV);
+
+		snprintf(filename, MAXFILENAME, "ntpkey_mv_%s",
+		    sys_hostname);
+		peer->ident_pkey = crypto_key(filename, &peer->fstamp);
+		if (peer->ident_pkey != NULL)
+			return (CRYPTO_MV);
 	}
 
 	/*
@@ -2183,7 +2202,7 @@ crypto_iff(
 	DSA_SIG	*sdsa;		/* DSA parameters */
 	BIGNUM	*bn, *bk;
 	u_int	len;
-	u_char	*ptr;
+	const u_char *ptr;
 	int	temp;
 
 	/*
@@ -2195,7 +2214,8 @@ crypto_iff(
 		return (XEVNT_PUB);
 	}
 	if (ntohl(ep->fstamp) != peer->fstamp) {
-		msyslog(LOG_INFO, "crypto_iff: invalid filestamp");
+		msyslog(LOG_INFO, "crypto_iff: invalid filestamp %u",
+		    ntohl(ep->fstamp));
 		return (XEVNT_FSP);
 	}
 	if ((dsa = peer->ident_pkey->pkey.dsa) == NULL) {
@@ -2470,7 +2490,7 @@ crypto_gq(
 	BN_CTX	*bctx;		/* BIGNUM context */
 	DSA_SIG	*sdsa;		/* RSA signature context fake */
 	BIGNUM	*y, *v;
-	u_char	*ptr;
+	const u_char *ptr;
 	u_int	len;
 	int	temp;
 
@@ -2483,7 +2503,8 @@ crypto_gq(
 		return (XEVNT_PUB);
 	}
 	if (ntohl(ep->fstamp) != peer->fstamp) {
-		msyslog(LOG_INFO, "crypto_gq: invalid filestamp");
+		msyslog(LOG_INFO, "crypto_gq: invalid filestamp %u",
+		    ntohl(ep->fstamp));
 		return (XEVNT_FSP);
 	}
 	if ((rsa = peer->ident_pkey->pkey.rsa) == NULL) {
@@ -2787,7 +2808,7 @@ crypto_mv(
 	BN_CTX	*bctx;		/* BIGNUM context */
 	BIGNUM	*k, *u, *v;
 	u_int	len;
-	u_char	*ptr;
+	const u_char *ptr;
 	int	temp;
 
 	/*
@@ -2799,7 +2820,8 @@ crypto_mv(
 		return (XEVNT_PUB);
 	}
 	if (ntohl(ep->fstamp) != peer->fstamp) {
-		msyslog(LOG_INFO, "crypto_mv: invalid filestamp");
+		msyslog(LOG_INFO, "crypto_mv: invalid filestamp %u",
+		    ntohl(ep->fstamp));
 		return (XEVNT_FSP);
 	}
 	if ((dsa = peer->ident_pkey->pkey.dsa) == NULL) {
@@ -3380,15 +3402,14 @@ crypto_key(
 	FILE	*str;		/* file handle */
 	EVP_PKEY *pkey = NULL;	/* public/private key */
 	char	filename[MAXFILENAME]; /* name of key file */
-	char	linkname[MAXFILENAME]; /* file link (for filestamp) */
+	char	linkname[MAXFILENAME]; /* filestamp buffer) */
 	u_char	statstr[NTP_MAXSTRLEN]; /* statistics for filegen */
-	int	rval;
 	u_char	*ptr;
 
 	/*
-	 * Open the key file. If the first character of the file
-	 * name is not '/', prepend the keys directory string. If
-	 * something goes wrong, abandon ship.
+	 * Open the key file. If the first character of the file name is
+	 * not '/', prepend the keys directory string. If something goes
+	 * wrong, abandon ship.
 	 */
 	if (*cp == '/')
 		strcpy(filename, cp);
@@ -3398,6 +3419,25 @@ crypto_key(
 	if (str == NULL)
 		return (NULL);
 
+	/*
+	 * Read the filestamp, which is contained in the first line.
+	 */
+	if ((ptr = fgets(linkname, MAXFILENAME, str)) == NULL) {
+		msyslog(LOG_ERR, "crypto_key: no data %s\n",
+		    filename);
+		return (NULL);
+	}
+	if ((ptr = strrchr(ptr, '.')) == NULL) {
+		msyslog(LOG_ERR, "crypto_key: no filestamp %s\n",
+		    filename);
+		return (NULL);
+	}
+	if (sscanf(++ptr, "%u", fstamp) != 1) {
+		msyslog(LOG_ERR, "crypto_key: invalid timestamp %s\n",
+		    filename);
+		return (NULL);
+	}
+
 	/*
 	 * Read and decrypt PEM-encoded private key.
 	 */
@@ -3410,27 +3450,11 @@ crypto_key(
 	}
 
 	/*
-	 * If a link is present, extract the filestamp from the linked
-	 * file name. If not, extract the filestamp from the file name
-	 * in the first line of the file. We don't need to check for
-	 * errors here, since the key has already been read
-	 * successfully.
+	 * Leave tracks in the cryptostats.
 	 */
-	rval = readlink(filename, linkname, MAXFILENAME - 1);
-	if (rval > 0) {
-		linkname[rval] = '\0';
-		ptr = strrchr(linkname, '.');
-	} else {
-		str = fopen(filename, "r");
-		ptr = fgets(linkname, MAXFILENAME, str);
-		fclose(str);
-		ptr = strrchr(ptr, '.');
-	}
-	if (ptr != NULL)
-		sscanf(++ptr, "%u", fstamp);
-	else
-		*fstamp = 0;
-	sprintf(statstr, "%s link %d fs %u mod %d", cp, rval, *fstamp,
+	if ((ptr = strrchr(linkname, '\n')) != NULL)
+		*ptr = '\0'; 
+	sprintf(statstr, "%s mod %d", &linkname[2],
 	    EVP_PKEY_size(pkey) * 8);
 	record_crypto_stats(NULL, statstr);
 #ifdef DEBUG
@@ -3465,10 +3489,9 @@ crypto_cert(
 	struct cert_info *ret; /* certificate information */
 	FILE	*str;		/* file handle */
 	char	filename[MAXFILENAME]; /* name of certificate file */
-	char	linkname[MAXFILENAME]; /* file link (for filestamp) */
+	char	linkname[MAXFILENAME]; /* filestamp buffer */
 	u_char	statstr[NTP_MAXSTRLEN]; /* statistics for filegen */
 	tstamp_t fstamp;	/* filestamp */
-	int	rval;
 	u_int	len;
 	u_char	*ptr;
 	char	*name, *header;
@@ -3487,6 +3510,25 @@ crypto_cert(
 	if (str == NULL)
 		return (NULL);
 
+	/*
+	 * Read the filestamp, which is contained in the first line.
+	 */
+	if ((ptr = fgets(linkname, MAXFILENAME, str)) == NULL) {
+		msyslog(LOG_ERR, "crypto_cert: no data %s\n",
+		    filename);
+		return (NULL);
+	}
+	if ((ptr = strrchr(ptr, '.')) == NULL) {
+		msyslog(LOG_ERR, "crypto_cert: no filestamp %s\n",
+		    filename);
+		return (NULL);
+	}
+	if (sscanf(++ptr, "%u", &fstamp) != 1) {
+		msyslog(LOG_ERR, "crypto_cert: invalid filestamp %s\n",
+		    filename);
+		return (NULL);
+	}
+
 	/*
 	 * Read PEM-encoded certificate and install.
 	 */
@@ -3505,21 +3547,6 @@ crypto_cert(
 	}
 	free(name);
 
-	/*
-	 * Extract filestamp if present.
-	 */
-	rval = readlink(filename, linkname, MAXFILENAME - 1);
-	if (rval > 0) {
-		linkname[rval] = '\0';
-		ptr = strrchr(linkname, '.');
-	} else {
-		ptr = strrchr(filename, '.');
-	}
-	if (ptr != NULL)
-		sscanf(++ptr, "%u", &fstamp);
-	else
-		fstamp = 0;
-
 	/*
 	 * Parse certificate and generate info/value structure.
 	 */
@@ -3527,8 +3554,10 @@ crypto_cert(
 	free(data);
 	if (ret == NULL)
 		return (NULL);
-	sprintf(statstr, "%s 0x%x link %d fs %u len %u", cp, ret->flags,
-	    rval, fstamp, len);
+	if ((ptr = strrchr(linkname, '\n')) != NULL)
+		*ptr = '\0'; 
+	sprintf(statstr, "%s 0x%x len %u", &linkname[2], ret->flags,
+	    len);
 	record_crypto_stats(NULL, statstr);
 #ifdef DEBUG
 	if (debug)
diff --git a/util/ntp-keygen.c b/util/ntp-keygen.c
index 024c531ae1..b1bd18a8ea 100644
--- a/util/ntp-keygen.c
+++ b/util/ntp-keygen.c
@@ -375,6 +375,8 @@ main(
 		}
 	}
 
+	if (passwd1 != NULL && passwd2 == NULL)
+		passwd2 = passwd1;
 #ifdef OPENSSL
 	/*
 	 * Seed random number generator and grow weeds.

Reference Clock Options

Related Links

Copyright Notice

NTP Debugging Techniques

More Help

Initial Startup

Verifying Correct Operation

Large Frequency Errors

Debugging Checklist

External Clock Discipline and the Local Clock Driver