<body>
<h3>Reference Clock Options</h3>
- <img src="pic/stack1a.jpg" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/stack1a.jpg" alt="gif" align="left">
<p>See the radios, all in a row.</p>
- <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:36</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">15:48</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="240">Sunday, February 02, 2003</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<body>
<h3>Copyright Notice</h3>
<img src="pic/sheepb.jpg" alt="jpg" align="left"> "Clone me," says Dolly sheepishly
- <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:31</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">15:44</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="240">Sunday, February 02, 2003</csobj></p>
<br clear="left">
<hr>
<p>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.<br>
<pre>
***********************************************************************
* *
-* 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 *
<h3>NTP Debugging Techniques</h3>
<img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We make house calls and bring our own bugs.</p>
- <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">21:30</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="230">Sunday, January 26, 2003</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">15:34</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="240">Sunday, February 02, 2003</csobj></p>
<br clear="left">
<h4>More Help</h4>
<script type="text/javascript" language="javascript" src="scripts/links12.txt"></script>
<p>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 <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.</p>
<h4>Initial Startup</h4>
<p>When started for the first time, the frequency file, usually called <tt>ntp.drift</tt>, 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 <tt>ntp.drift</tt> file. When restarted after that, the daemon reads the frequency offset from the <tt>ntp.drift</tt> file and avoids the training routine.</p>
- <p>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 <tt>iburst</tt> configuration option. </p>
+ <p>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 <tt>iburst</tt> configuration option.</p>
<p>The best way to verify correct operation is using the <a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a> and <a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a> utility programs, either on the server itself or from another machine elsewhere in the network. The <tt>ntpq</tt> program implements the management functions specified in the NTP specification <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.ps">RFC-1305, Appendix A</a>. The <tt>ntpdc</tt> 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 <tt>ntpdc</tt>, additional ones intended for serious debugging. In addition, the <tt>ntpdc</tt> program can be used to selectively reconfigure and enable or disable some functions while the daemon is running.</p>
<p>In extreme cases with elusive bugs, the daemon can operate in two modes, depending on the presence of the <tt>-d</tt> command-line debug switch. If not present, the daemon detaches from the controlling terminal and proceeds autonomously. If one or more <tt>-d</tt> 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 <tt>-d</tt> 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 <tt>grep</tt> and specifying the keyword of the trace you want to see.</p>
<p>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 <tt>/etc/services</tt> file (or equivalent in some systems). <b>Note that NTP does not use TCP in any form. Also note that NTP requires 123 for both source and destination ports.</b> These facts should be pointed out to firewall administrators.</p>
- <p>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.</p>
+ <p>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.</p>
<p>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 <tt>ping</tt> command. The Unix <tt>traceroute</tt> or Windows <tt>tracert</tt> 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.</p>
<p>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 <tt>date</tt> command, or by the <tt>ntpdate</tt> or <tt>ntpd -q</tt> commands. The panic threshold can be changed by the <tt>tinker panic</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> page. The panic threshold can be disabled for the first measurement by the <tt>-g</tt> command line option described on the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page.</p>
- <p>If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 12
5 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 <tt>-x</tt> command line option described on the <tt>ntpd</tt> 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 <tt>tinker step</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> 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 <a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a> 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.</p>
+ <p>If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 12
8 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 <tt>-x</tt> command line option described on the <tt>ntpd</tt> 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 <tt>tinker step</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> 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 <a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a> 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.</p>
<p>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 <tt>tinker stepout</tt> command discribed on the Miscellaneous Options page.</p>
<p>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 <tt>ntp.drift</tt> file. If the frequency error is over 500 PPM, convergence will never occur and occasional step adjustments will occur indefinitely.</p>
<h4>Verifying Correct Operation</h4>
*pogo.udel.edu .GPS1. 1 u 95 128 377 0.607 0.123 0.027
</pre>
<p>The host names or addresses shown in the <tt>remote</tt> 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 <tt>refid</tt> column shows the current source of synchronization, while the <tt>st</tt> column reveals the stratum, <tt>t</tt> the type (<tt>u</tt> = unicast, <tt>m</tt> = multicast, <tt>l</tt> = local, <tt>-</tt> = don't know), and <tt>poll</tt> the poll interval in seconds. The <tt>when</tt> column shows the time since the peer was last heard in seconds, while the <tt>reach</tt> 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 <tt>dispersion</tt> column has been replaced by the <tt>jitter</tt> column.</p>
- <p>As per the NTP specification RFC-1305, when the <tt>stratum</tt> is between 0 and 15 for a NTP server, the <tt>refid</tt> field shows the server DNS name or, if not found, the IP address in dotted-quad. When the <tt>stratum</tt> 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 <tt>stratum</tt> for a NTP server is 0 (appears as 16 in the billboards), the status cannot be determined. As a help in debugging, the <tt>refid</tt> field is set as follows.</p>
- <p>Peer Variables</p>
+ <p>As per the NTP specification RFC-1305, when the <tt>stratum</tt> is between 0 and 15 for a NTP server, the <tt>refid</tt> field shows the server DNS name or, if not found, the IP address in dotted-quad. When the <tt>stratum</tt> 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 <tt>stratum</tt> for a NTP server is 0 (appears as 16 in the billboards), the status cannot be determined. As a help in debugging, the <tt>refid</tt> field is set to a four-character string called the kiss code. The current kiss codes are as as follows.</p>
+ <p>Peer Kiss Codes</p>
+ <p><tt>ACST</tt></p>
<dl>
- <dt><tt>ACST</tt>
<dd>The association belongs to a anycast server.
<dt><tt>AUTH</tt>
<dd>Server authentication failed. Please wait while the association is restarted.
<dt><tt>STEP</tt>
<dd>A step change in system time has occured, but the association has not yet resynchronized.
</dl>
- <p>System Variables</p>
+ <p>System Kiss Codes</p>
<dl>
<dt><tt>INIT</tt>
<dd>The system clock has not yet synchronized for the first time.
<dt><tt>STEP</tt>
<dd>A step change in system time has occured, but the system clock has not yet resynchronized.
</dl>
- <p>The tattletale symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked <tt>*</tt>, while additional peers designated acceptable for synchronization, but not currently selected, are marked <tt>+</tt>. Peers marked <tt>*</tt> and <tt>+</tt> 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 <tt>ntpq</tt> page for the meaning of these symbols.</p>
+ <p>The tattletale symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked <tt>*</tt>, while additional peers designated acceptable for synchronization are marked <tt>+</tt>. Peers marked <tt>*</tt> and <tt>+</tt> 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 <tt>ntpq</tt> page for the meaning of these symbols.</p>
<p>Additional details for each peer separately can be determined by the following procedure. First, use the <tt>as</tt> command to display an index of association identifiers, such as</p>
<pre>
ntpq> as
<p>An explanation about most of these variables is in the RFC-1305 specification. The most useful ones include <tt>clock</tt>, which shows when the clock was last adjusted, and <tt>reftime</tt>, which shows when the server clock of <tt>refid</tt> was last adjusted. The <tt>version</tt>, <tt>processor</tt> and <tt>system</tt> values are very helpful when included in bug reports. The mean millisecond time offset (<tt>phase</tt>) and deviation (<tt>jitter</tt>) monitor the clock quality, while the mean PPM frequency offset (<tt>frequency</tt>) and deviation (<tt>stability</tt>) 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.</p>
<p>Among the new variables added for NTP Version 4 are the <tt>hostname</tt>, <tt>signature</tt>, <tt>flags, hostkey, refresh </tt>and<tt> cert</tt>, which are used for the Autokey public-key cryptography described on the <a href="authopt.html">Authentication Options</a> 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.</p>
<p>When nothing seems to happen in the <tt>pe</tt> 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 <a href="accopt.html">Access Control Options</a> page. Another common problem is that the server is down or running in unsynchronized mode due to a local problem. Use the <tt>ntpq</tt> program to spy on the server variables in the same way you can spy on your own.</p>
- <p>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.</p>
+ <p>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.</p>
<h4>Large Frequency Errors</h4>
<p>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 <tt>ntp.drift</tt> 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.</p>
<p>In order to determine if excessive frequency error is a problem, observe the nominal <tt>filtoffset</tt> 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 <tt><a href="tickadj.html">tickadj</a></tt> utility and the <tt>-s</tt> command line argument. For other systems this can be done using a command in the system startup file.</p>
<p>Reliable source authentication requires the use of symmetric key or public key cryptography, as described on the <a href="authopt.html">Authentication Options</a> 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 <a href="keygen.html"><tt>ntp-keygen</tt></a> program.</p>
<p>Problems with symmetric key authentication are usually due to mismatched keys or improper use of the <tt>trustedkey</tt> command. A simple way to check for problems is to use the trace facility, which is enabled using the <tt>ntpd -d</tt> command line. As each packet is received a trace line is displayed which shows the authentication status in the <tt>auth</tt> field. A status of 1 indicates the packet was successful authenticated; otherwise it has failed.</p>
<p>A common misconception is the implication of the <tt>auth</tt> bit in the <tt>enable</tt> and <tt>disable</tt> commands. <b>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.</b> 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.</p>
- <p>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 <tt>ntpd</tt> 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 <a href="authopt.html">Authentication Options</a> page. Common problems with configuration and key generation are mismatched key files, broken links and missing or broken random seed file.</p>
+ <p>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 <tt>ntpd</tt> 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 <a href="authopt.html">Authentication Options</a> page. Common problems with configuration and key generation are mismatched key files, broken links and missing or broken random seed file.</p>
<p>As in the symmetric key cryptography case, the trace facility is a good way to verify correct operation. A statistics file <tt>cryptostats</tt> 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.</p>
<p>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 <tt>auth</tt> 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.</p>
<h4>Debugging Checklist</h4>
<p>If the <tt>ntpq</tt> or <tt>ntpdc</tt> 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:</p>
<ol>
<li>Verify the <tt>/etc/services</tt> 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.
- <li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems. Check to be sure that only one copy of <tt>ntpd</tt> is running.
+ <li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems. Common system log messages are summarized on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page. Check to be sure that only one copy of <tt>ntpd</tt> is running.
<li>Verify using <tt>ping</tt> or other utility that packets actually do make the round trip between the client and server. Verify using <tt>nslookup</tt> or other utility that the DNS server names do exist and resolve to valid Internet addresses.
+
+ <li>Check that the remote NTP server is up and running. The usual evidence that it is not is a <tt>Connection refused</tt> message.
<li>Using the <tt>ntpdc</tt> 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.
- <li>If both the sent and received counters do increment, but the <tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt> 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 <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt> page.
- <li>If the <tt>reach</tt> values in the <tt>pe</tt> 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 <tt>ntpq</tt> 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.
+ <li>If both the sent and received counters do increment, but the <tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt> 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 <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt> page. It could be that the server has disabled access for the client address, in which case the refid field in the <tt>ntpq pe</tt> billboard will show a kiss code. See earlier on this page for a list of kiss codes and their meaning. <li>If the <tt>reach</tt> values in the <tt>pe</tt> 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 <tt>ntpq</tt> 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.
<li>If all else fails, see the FAQ and/or the discussion and briefings at the NTP Project page.
</ol>
<hr>
<body>
<h3>External Clock Discipline and the Local Clock Driver</h3>
- <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">14:44</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="235">Monday, January 20, 2003</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">15:41</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="240">Sunday, February 02, 2003</csobj></p>
<hr>
- <p>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.</p>
+ <p>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 <tt>Lockclock</tt> algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.</p>
<p>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> 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.</p>
<p>Control and monitoring functions for the external clock and driver are implemented using the <a href="drivers/driver1.html">Local Clock (type 1) driver</a> and the <tt>ntp_adjtime()</tt> 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.</p>
<p>When the external clock is enabled, <tt>ntpd</tt> 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 <tt>ntpd</tt>; 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.</p>
<p>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:</p>
- <p>ntp__enable. set/reset by enable command. enables ntp clock discipline</p>
- <p>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.</p>
- <p>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.</p>
- <p>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.</p>
+ <p><tt>ntp_enable</tt>. set/reset by the <tt>enable</tt> command. enables ntp clock discipline</p>
+ <p><tt>ntp_contro</tt>l. set during initial configuration if kernel support is available</p>
+ <p><tt>kern_enable</tt> Set/reset by the <tt>enable</tt> command</p>
+ <p>If the <tt>kern_enable</tt> 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 <tt>ntp_adjtime()</tt>. 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.</p>
+ <p>The <tt>pps_update</tt> bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.</p>
+ <p>The <tt>pps_contro</tt>l 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.</p>
+ <p>The <tt>ntp_enable</tt> and <tt>kern_enable</tt> 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 <tt>pps_update</tt> switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The <tt>ntp_control</tt> switch is set during configuration by interrogating the kernel. If both the <tt>kern_enable</tt> and <tt>ntp_control</tt> switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.</p>
+ <p>The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the <tt>ntp_adjtime()</tt> 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.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
/*
* 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);
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",
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",
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);
}
/*
DSA_SIG *sdsa; /* DSA parameters */
BIGNUM *bn, *bk;
u_int len;
- u_char *ptr;
+ const u_char *ptr;
int temp;
/*
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) {
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;
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) {
BN_CTX *bctx; /* BIGNUM context */
BIGNUM *k, *u, *v;
u_int len;
- u_char *ptr;
+ const u_char *ptr;
int temp;
/*
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) {
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);
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.
*/
}
/*
- * 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
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;
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.
*/
}
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.
*/
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)
}
}
+ if (passwd1 != NULL && passwd2 == NULL)
+ passwd2 = passwd1;
#ifdef OPENSSL
/*
* Seed random number generator and grow weeds.
projects / thirdparty / ntp.git / commitdiff
