+* Documentation updates from Dave Mills.
(4.2.7p93) 2010/12/13 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1510] from 4.2.6p3-RC12: Add modes 20/21 for driver 8 to support
RAWDCF @ 75 baud.
color: #FF0000;
font-weight: bold;
}
+.style1 {color: #FF0000}
</style>
</head>
<body>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->31-Oct-2010 3:55<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->15-Dec-2010 2:56<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<p>Unless noted otherwise, further information about these commands is on the <a href="authentic.html">Authentication Support</a> page.</p>
<dl>
<dt id=automax><tt>automax [<i>logsec</i>]</tt></dt>
- <dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol, as a power of 2 in seconds. Note that the size of the key list for each association depends on this interval and the current poll interval. The default interval is 12 (about 1.1 h). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information.</dd>
+ <dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol, as a power of 2 in seconds. Note that the size of the key list for each association depends on this interval and the current poll interval. The default interval is 12 (about 1.1 h
r). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information.</dd>
<dt id="controlkey"><tt>controlkey <i>keyid</i></tt></dt>
<dd>Specifies the key ID for the <a
href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the
inclusive.</dd>
<dt id="crypto"><tt>crypto [digest</tt> <em><tt>digest</tt></em><tt>]</tt> <tt>[host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>] [randfile <i>file</i>]</tt></dt>
<dd>This command activates the Autokey public key cryptography
- and loads the required host key and public certificate. If one or more files
- are left unspecified, the default names are used as described below. Unless
+ and loads the required host keys and certificate. If one or more files
+ are unspecified, the default names are used. Unless
the complete path and name of the file are specified, the location of a file
is relative to the keys directory specified in the <tt>keysdir</tt> configuration
- command
or default <tt>/usr/local/etc</tt>. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information. Following are the options.</dd>
+ command
with default <tt>/usr/local/etc</tt>. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information. Following are the options.</dd>
<dd>
<dl>
<dt><tt>digest</tt> <em><tt>digest</tt></em></dt>
the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>.</dd>
<dt><tt>host <i>name</i></tt></dt>
<dd>Specifies the string used when constructing the names for the host, sign
- and certificate files generated by the <tt>ntp-keygen</tt> program with the <tt>-s <i>subject_name</i></tt> option.</dd>
- <dt><tt>ident <i>name</i></tt></dt>
- <dd>Specifies the string used in constructing the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>issuer_name</i></tt> option.</dd>
+ and certificate files generated by the <tt>ntp-keygen</tt> program with the <tt>-s <i>host</i></tt> option.</dd>
+ <dd><span class="style1">Note: In the latest Autokey version, this option is deprecated. See the <a href="autokey.html">Autokey Public-Key Authentication</a> page for further information.</span></a>
+ <dt> </dt>
+ <dt><tt>ident <i>group</i></tt></dt>
+ <dd>Specifies the string used in retrieving the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>group</i></tt> option.</dd>
<dt><tt>pw <i>password</i></tt></dt>
<dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program with the <tt>-p</tt> option.</dd>
<dt><tt>randfile <i>file</i></tt></dt>
</dd>
<dt id="keys"><tt>keys <i>path</i></tt></dt>
<dd>Specifies the complete directory path for the key file containing the key IDs, key types and keys used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option. Note that the directory path for Autokey cryptographic media is specified by the <tt>keysdir</tt> command.</dd>
- <dt id="keysdir"><tt>keysdir <i>path</i></tt>K</dt>
+ <dt id="keysdir"><tt>keysdir <i>path</i></tt></dt>
<dd>Specifies the complete directory path for the Autokey cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>. Note that the path for the symmetric keys file is specified by the <tt>keys</tt> command.</dd>
<dt id="requestkey"><tt>requestkey <i>keyid</i></tt></dt>
<dd>Specifies the key ID for the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which
for a <a href="#trustedkey">trusted key</a>, in the range 1 to
65534, inclusive.</dd>
<dt id="revoke"><tt>revoke [<i>logsec</i>]</tt></dt>
- <dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. See the <a href="autokey.html">Autokey Public-Key Authentication</a>a page for further information.</dd>
+ <dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds, with default 17 (36 hr). See the <a href="autokey.html">Autokey Public-Key Authentication</a> page for further information.</dd>
<dt id="trustedkey"><tt>trustedkey [<i>keyid</i> | (<i>lowid</i> ... <i>highid</i>)] [...]</tt></dt>
<dd>Specifies the key ID(s) which are trusted for the purposes of
authenticating peers with symmetric key cryptography. Key IDs
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Dec-2010 21:14<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->15-Dec-2010 6:06<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
<hr>
<h4 id="intro">Introduction</h4>
<p>This distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is specified when the distribution is built.</p>
-<p> Public key cryptography is generally considered more secure than symmetric key cryptography. Symmetic key cryptography is based on a shared secret which must be distributed by secure means to all participats. Public key cryptography is based on a private secret key known only to the originator and a public key known to all participants. A recipient can verify the originator has the correct private key using the public key and any of several digital signature algortihms.</p>
+<p> Public key cryptography is generally considered more secure than symmetric key cryptography. Symmetic key cryptography is based on a shared secret key which must be distributed by secure means to all participats. Public key cryptography is based on a private secret key known only to the originator and a public key known to all participants. A recipient can verify the originator has the correct private key using the public key and any of several digital signature algortihms.</p>
<p>The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using message digest algorithms, such as MD5 or SHA, and verifies the source using any of several digital signature schemes, such as RSA or DSA. As used in Autokey, message digests are exceptionlly difficult to cryptanalyze, as the keys are used only once.</p>
-<p> Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. Identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficulat to cryptanalyze, as the challenge/response
e exchange data are used only once. They are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
-<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers are operated outside firewall perimeters.</p>
+<p> Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. Identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficulat to cryptanalyze, as the challenge/response exchange data are used only once. They are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
+<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same IP addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers and clients are operated outside firewall perimeters.</p>
<p>Auokey is designed to authenticate servers to clients, not the other way around as in SSH. An Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme described in RFC 5905, whle a client is free to choose between the various options. It is important to understand that these provisions are optional and that selection of which option is at the discretion of the client. If the client does not require authentication, it is free to ignore it, even if some other client of the same server elects to participate in either symmetric key or public key cryptography.</p>
-<p> Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library and the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the server and the time period over which the the server public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produces with the Autokey host name as subject and the host that signs the certificate as issuer.</p>
+<p> Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the server and the time period over which the the server public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produced with the Autokey host name as subject and the host that signs the certificate as issuer.</p>
+<p>There are two timeouts associated with the Autokey scheme. The <em>key list timeout</em> is set by the <tt>automax</tt> command, which specifies the interval between generating new key lists by the client. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The <em>revoke timeout</em> is set by the <tt>revoke</tt> command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.</p>
<h4 id="cert">Autokey Subnets</h4>
-<p> An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or a private, dedicated NTP subnet. Autokey hosts operate as servers, clients or both at the same time.</p>
-<p>A certificate trail is a sequence of certificates, each signed by a host nearer the THs and terminating at the self-signed certificate of a Th. As the Autokey protocol proceeds, each client provides its self-signed certificate to a server nearer the THs for signature. In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired. While the certificate trail authenticates each host on the trail to the THs, it does not verify the validity of the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.</p>
-<p>The Autokey protocol runs for each association separately. During the protocol the client recursively obtains all the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidate, but marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it. </p>
+<p> An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or an NTP secure group as described in the next section.. Autokey hosts operate as servers, clients or both at the same time.</p>
+<p>A certificate trail is a sequence of certificates, each signed by a host nearer the THs and terminating at the self-signed certificate of a TH. As the Autokey protocol proceeds, each client provides its self-signed certificate to a server nearer the THs for signature. In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocool.</p>
+<p>The Autokey protocol runs for each association separately. During the protocol the client recursively obtains all the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it. </p>
<p>The certificates derived from each association are combined in the cache with duplicates suppressed. If it happens that two different associations contribute certificates to the cache, a certificate on the trail from one association could expire before any on another trail. In this case the remaining trails will survive until the expired certificate is replaced. Once saved in the cache, a certificate remains valid until it expires or is replaced by a new one.</p>
-<p> It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains validated until it is demobilized, even if certificates on the trail to the THs expire.</p>
+<p> It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains valid until it is demobilized, even if certificates on the trail to the THs expire.</p>
<h4 id="group">NTP Secure Groups</h4>
-<p>NTP security groups are an
d extension of NTP subnets. They include in addition to certificate trails one or another identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page. NTP secure groups are used to define cryptographic compartments and security
- hierarchies. The identity scheme insures that the server is authentic and not masqueraded by an intruder acting as a middleman.</p>
-<p> As in NTP subnets, the THs are at the lowest stratum of the secure group. For secure group THs the string specified by the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program is the name used as the subject and issuer of the trusted certificate and is also the name of the secure group. This name must match the <tt>ident</tt> option
- of the <tt>crypto</tt> command, which is the group name for all group hosts and the
- name used in the identity files. The file naming conventions are described on
+<p>NTP security groups are an
extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page. NTP secure groups are used to define cryptographic compartments and security
+hierarchies. The identity scheme insures that the server is authentic and not masqueraded by an intruder acting as a middleman.</p>
+<p> As in NTP subnet, NTP secure groups are configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH. In addition, each group host verifies the server has the secret group key using an identity exchange.</p>
+<p> For secure group servers, the string specified by the <tt>-i</tt> option of the <tt>ntp-keygen</tt> program is the name of the secure group. For secure group servers this name must match the <tt>ident</tt> option
+ of the <tt>crypto</tt> command. For secure group clients, this name must match the <tt>ident</tt> option of the <tt>server</tt> command. This name is also used in the identity keys and parameters file names. The file naming conventions are described on
the <a href="keygen.html">ntp-keygen</a> page.</p>
-<p>The Autokey identity schemes involve a challenge-response exchange where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and a secret key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash. Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secure group key to persist long after the longest period of certificate validity. In the Schnorr IFF scheme considered in this section, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.</p>
-<p>As in NTP subnets, each secure group includes one or more trusted hosts (THs) operating at the lowest stratum in the group. For THs the group name specified by the -i option of the ntp_keygen program and the ident option of the crypto command is used as the subject and issuer of the TH self-signed trusted certificate. For the IFF scheme, the other group hosts need only the crypto command with no options. </p>
-<p>As in NTP subnet, NTP secure group hosts are configured as an acyclic tree rooted on the THs. All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH. In addition, each group host verifies the server has the secret key using the identity exchange. When a host starts up, it recursively retrieves the certificates along the trail to the TH in order to verify group membership and avoid masquerade and middleman attacks.</p>
-<h4 id="cfg">NTP Secure Group Configuration</h4>
-<p> The simplest scenario consists of a TH where the host name of the TH is also the name of the group. For the simplest identity scheme TC, the TH generates host key and trusted certificate files using the <tt>ntp-keygen -T</tt> command, while the remaining group hosts use the same command with no options to generate the host key and public certificate files. All hosts use the <tt>crypto</tt> configuration command with no options. Configuration with passwords is described in the <a href="keygen.html">ntp-keygen</a> page. All group hosts are configured as an acyclic tree with root the TH.</p>
-<p>An NTP secure group is an NTP subnet consisting of one or more low-stratum trusted hosts (THs) as the root from which all other group hosts derive synchronization directly or indirectly. For authentication purposes all hosts in a group must have the same group name specified by the <tt>ident</tt> option of the <tt>crypto</tt> command, in the case of servers, or by the <tt>ident</tt> option of the <tt>server</tt> configuration command, in the case of clients. Group names are used only for authentication purposes and have nothing to do with DNS names.</p>
-<p> For THs the group name is specified by the <tt>-i</tt> option of the <tt>ntp-keygen</tt> program and must match the <tt>ident</tt> option of the <tt>crypto</tt> configuration command. For other hosts the group name is specified by the <tt>ident</tt> option of the <tt>server</tt> configuration command. <span class="style1">In the latest version of this program, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></p>
-<p>As described on the <a href="authopt.html">Authentication Options</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted keys file and a nonencrypted parameters file, which usually contains a subset of the keys file. In general, NTP hosts operating as certificate authorities (CAs) use the keys file and clients use the parameters file. The TAs include the THs and those group servers with dependent clients.</p>
-<p>The parameters files are public; they can be stored in a public place and sent in the clear. The keys files are encrypted with the local password. To retrieve the keys file, a host can send a mail request to the TA including its local password. The TA encrypts the keys file with this password and returns it as an attachment. The attachment is then copied intact to the keys directory with name given in the first line of the file, but all in lower case and with the filestamp deleted. Alternatively, the parameters file can be generated using the <tt>-e</tt> option of the <a href="keygen.html">ntp-keygen</a> program.</p>
-<p>When an identity scheme is included, for example IFF, the TH generates host
- key, trusted certificate and private server identity key files using the <tt>ntp-keygen
- -T -I -i <i>group</i></tt> command, where <tt><i>group</i></tt> is the group
- name. The remaining group hosts use the same command as above. All hosts
- use the <tt>crypto ident group<i></i></tt> configuration command.</p>
-<p>Hosts with no dependent clients can retrieve client parameter files from an
- archive or web page. The <tt>ntp-keygen</tt> can export these data using the <tt>-e</tt> option.
- Hosts with dependent clients other than the TH must retrieve copies of the server
- key files using secure means. The <tt>ntp-keygen</tt> can export these data
- using the <tt>-q</tt> option. In either case the data are installed as a file
+<p><span class="style1">In the latest Autokey version, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></p>
+<p>The Autokey identity schemes involve a challenge-response exchange where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash. Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secure group key to persist long after the longest period of certificate validity. In the Schnorr IFF scheme considered later on this page, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.</p>
+<p>As described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted keys file and a nonencrypted parameters file, which usually contains a subset of the keys file. In general, NTP servers operating as certificate authorities (CAs) use the keys file and clients use the parameters file. The CAs include the THs and those group servers with dependent clients.</p>
+<p> Hosts with no dependent clients can retrieve client parameter files from an
+ archive or web page. The <tt>ntp-keygen</tt> program can export these data using the <tt>-e</tt> option.
+ Hosts with dependent clients other than the CA must retrieve copies of the server
+ key files using secure means. The <tt>ntp-keygen</tt> program can export these data
+ using the <tt>-q</tt> option and chosen remote password. In either case the data are installed as a file
and then renamed using the name given as the first line in the file, but without
- the filestamp.</p>
-<h4 id="config">Configuration - Authentication Scheme</h4>
-<p>Autokey has an intimidating number of authentication options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. <tt>time.nist.gov,</tt> as root:</p>
+the filestamp.</p>
+<h4 id="config2">Configuration - Authentication Schemes</h4>
+<p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. <tt>time.nist.gov,</tt> as root:</p>
<p><tt># cd /usr/local/etc<br>
-# ntp-keygen -T</tt></p>
+ # ntp-keygen -T</tt></p>
<p>This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. Include in the <tt>ntp.conf</tt> configuration file something like</p>
<p><tt># disable kernel<br>
# server 127.127.18.1 minpoll 12 maxpoll 17 # ACTS modem<br>
-# phone atdt913035547785 atddt913034944774<br>
+ # phone atdt913035547785 atddt913034944774<br>
# crypto<br>
-# driftfile /etc/ntp.drift</tt></p>
+ # driftfile /etc/ntp.drift</tt></p>
<p>Note the first three lines are specific to the ACTS driver and NIST modem telephone numbers. The second number will be tried if the first times out. Alternatively, any other reference clock can be used, or even another time server.</p>
<p>For each client, e.g. <tt>grundoon.udel.edu,</tt> as root:</p>
<p><tt># cd /usr/local/etc<br>
-# ntp-keygen</tt></p>
+ # ntp-keygen</tt></p>
<p>(There is no -<tt>T</tt> option). Include in the <tt>ntp.conf</tt> configuration file something like</p>
<p><tt># server time.nist.gov iburst autokey<br>
- # crypto<br>
-# driftfile /etc/ntp.drift</tt></p>
+ # crypto<br>
+ # driftfile /etc/ntp.drift</tt></p>
<p>It is possible to configure clients of server <tt>grundoon.udel.edu</tt> in the same way with the server line pointing to <tt>grundoon.udel.edu</tt>. Dependent clients authenticate to <tt>time.nistg.gov</tt> through <tt>grundoon.udel.edu</tt>.</p>
-<p>In the above configuration examples, the default Autokey host name is the string returned by the Unix <tt>gethostname()</tt> library routine. This name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted key files. The Autokey host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> command.</p>
+<p>In the above configuration examples, the default Autokey host name is the string returned by the Unix <tt>gethostname()</tt> library routine. However, this name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys files. The Autokey host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> command.</p>
<h4 ident="ident">Configuration - Identity Schemes</h4>
-<p>An authentication scheme such as TC can be augmented by an identify scheme to form a secure group. For example, the TA generates encrypted host key and IFF key files and nonencrypted trusted certificate using the command</p>
-<p><tt>ntp-keygen -p <em>server_password </em>-T -I -i group<i>,</i></tt></p>
-<p>where <tt>group_name</tt> is the group name used by all hosts in the group. Each client host generates encrypted host keys and nonencrypted, nontrusted certificate using the command</p>
-<p><tt>ntp-keygen -p <i>client_passwd</i></tt></p>
-<p>Once these media have been generated, the TA can then generate the public parameters using the command</p>
-<p><tt>ntp-keygen -p <em>local_passwd</em> -e ><i>parameters_file</i></tt></p>
-<p>where the <tt>-e</tt> option redirects the unencrypted client parameters to the standard output stream for a mail application or stored locally for later distribution. In a similar fashion the <tt>-q</tt> option redirects the encrypted server keys to the standard output stream using the command</p>
-<p><tt>ntp-keygen -p <em>local_passwd</em> -q <em>remote_password</em> -e ><i>keys_file</i></tt></p>
+<p> For the simplest identity scheme TC, the server generates host keys, trusted certificate and identity files using an <tt>ntp-keygen </tt> program commadn with options specified in this section, while the clients use the same command with no options. The server uses the <tt>crypto</tt> command in the comnfiguration file with options specified in this section, while the clients use the same command with no options. Additonia client options are specified in the <tt>server</tt> command for each association. </p>
+<p> It's best to start with a functioning TC configuation and add commands as necessary. For example, the CA generates an encrypted server keys file using the command</p>
+<p><tt>ntp-keygen -I -i <em>group</em></tt>,</p>
+<p> where <em><tt>group</tt></em> is the group name used by all hosts in the group. This and following commands can be combined in a single command. The nonencrypted client parameters can be exported using the command</p>
+<p><tt>ntp-keygen -e ><i>file</i></tt>,</p>
+<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution. In a similar fashion the encrypted keys file can be exported using the command </p>
+<p><tt>ntp-keygen -q <em>passw2</em> ><i>file</i></tt>,</p>
+<p>where <em><tt>passwd2</tt></em> is the read password for another host. In either case the file is installed under the name<tt> </tt>found in the first line of the file, but converted to lower case and without the filestamp</p>
+<p>As in the TC scheme, the server includes a <tt>crypto</tt> command in the configuration file with the <tt>ident <em>group</em></tt> option. The crypto command in the client configuration file is unchanged, but the server command includes the <tt>ident <em>group</em></tt> option.</p>
<p>In special circumstances the Autokey message digest algorithm can be changed using the <tt>digest</tt> option of the <tt>crypto</tt> command. The digest algorithm is separate and distinct from the symmetric
-key message digest algorithm. If compliance with FIPS 140-2 is required,
-the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>. The Autokey message digest algorithm must be the same for all participants in the NTP subnet (see next section). The message digest/digital signature scheme can be changed for each server separately using the <tt>-c</tt> option of the <tt>ntp_keygen</tt> program. This applies only for clients of that server, which select whatever scheme the server specifies.</p>
-<p>It is important to note that certificates have a defined lifetime of one year from the time of creation. Sometime toward the end of the liftetime period, it is necessary to create a new certificate at both the server and client. For each server and client as root:</p>
-<p><tt># ntp_keygen</tt></p>
-<p>The options are copied from the current certificate.</p>
-<p>There are two timeouts associated with the Autokey scheme. The <em>key list timeout</em> is set by the <tt>automax</tt> command, which specifies the interval between generating new key lists by the client. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The <em>revoke timeout</em> is set by the <tt>revoke</tt> command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.</p>
+ key message digest algorithm. If compliance with FIPS 140-2 is required,
+the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.</p>
<h4 id="exam">Examples</h4>
<div align="center"> <img src="pic/group.gif" alt="gif"> </div>
<p>Consider a scenario involving three secure groups RED, GREEN and BLUE. RED and BLUE are typical of national laboratories providing certified time to the Internet at large. As shown ion the figure, RED TH mort and BLUE TH macabre run NTP symmetric mode with each other for monitoring or backup. For the purpose of illustration, assume both THs are primary servers. GREEN is typical of a large university providing certified time to the campus community. GREEN TH howland is a broadcast client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys. YELLOW is a client of GREEN and for purposes of illustration a TH for YELLOW.</p>
<p>The BLUE TH macabre uses configuration commands</p>
<p><tt>crypto pw qqsv ident blue</tt><br>
- <tt>peer mort autokey</tt><br>
+ <tt>peer mort autokey ident red</tt><br>
<tt>broadcast <i>address</i> autokey</tt></p>
<p>where <tt>qqsv</tt> is the password for macabre files and <i>address</i> is the broadcast address for the local LAN. It generates BLUE files using the commands</p>
<p><tt>ntp-keygen -p qqsv -T -G -i blue</tt><br>
<p>The first line generates the host, trusted certificate and private GQ server keys file. The second generates the public GQ client parameters file, which can have any nonconflicting mnemonic name.</p>
<p>The RED TH mort uses configuration commands</p>
<p><tt>crypto pw xxx ident red</tt><br>
- <tt>peer macabre autokey</tt><br>
+ <tt>peer macabre autokey ident blue</tt><br>
<tt>broadcast <i>address</i> autokey</tt></p>
<p>where <tt>xxx</tt> is the password for mort files. It generates RED files using the commands</p>
<p><tt>ntp-keygen -p xxx -T -I -i red</tt><br>
<tt>ntp-keygen -p xxx -e >ntpkey_iffpar_red</tt></p>
<p> The GREEN TH howland uses configuration commands</p>
<p><tt>crypto pw yyy ident green</tt><br>
- <tt>broadcastclient</tt></p>
+ <tt>broadcastclient ident red blue</tt></p>
<p>where <tt>yyy</tt> is the password for howland files. It generates GREEN files using the commands</p>
<p><tt>ntp-keygen -p yyy -T -G -i green</tt><br>
<tt>ntp-keygen -p yyy -e >ntpkey_gqpar_green</tt><br>
third line generates a copy of the private GREEN server file for use on another
server in the same group, say YELLOW, but encrypted with the <tt>zzz</tt> password.</p>
<p>A client of GREEN, for example YELLOW, uses the configuration commands</p>
-<p><tt>crypto pw abc ident green</tt><br>
- <tt>server howland autokey</tt></p>
+<p><tt>crypto pw abc</tt><br>
+ <tt>server howland autokey ident red</tt></p>
<p>where <tt>abc</tt> is the password for its files. It generates files using the command</p>
<p><tt>ntp-keygen -p abc</tt></p>
<p>The client retrieves the client file for that group from a public archive or web page using nonsecure means. In addition, each server in a group retrieves the private server keys file from the TH of that group, but it is encrypted and so must be sent using secure means. The files are installed in the keys directory with name taken from the first line in the file, but without the filestamp.</p>
</head>
<body>
<h3>Copyright Notice</h3>
-<img src="pic/sheepb.jpg" alt="jpg" align="left"> "Clone me," says Dolly sheepishly.
-<p>Last update:
- <!-- #BeginDate format:En2m -->03-Sep-2010 21:20<!-- #EndDate -->
- UTC<br clear="left">
+<img src="pic/sheepb.jpg" alt="jpg" align="left"> "Clone me," says Dolly sheepishly.
+<p>Last update: 03-Sep-2010 21:20 UTC<br clear="left">
</p>
<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.</p>
-<pre>
-***********************************************************************
-* *
-* Copyright (c) University of Delaware 1992-2010 *
-* *
-* Permission to use, copy, modify, and distribute this software and *
-* its documentation for any purpose with or without fee is hereby *
-* granted, provided that the above copyright notice appears in all *
-* copies and that both the copyright notice and this permission *
-* notice appear in supporting documentation, and that the name *
-* University of Delaware not be used in advertising or publicity *
-* pertaining to distribution of the software without specific, *
-* written prior permission. The University of Delaware makes no *
-* representations about the suitability this software for any *
-* purpose. It is provided "as is" without express or implied *
-* warranty. *
-* *
-***********************************************************************
-</pre>
-<p>The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.</p>
+<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.</p>
+<pre>*********************************************************************** * * * Copyright (c) University of Delaware 1992-2010 * * * * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose with or without fee is hereby * * granted, provided that the above copyright notice appears in all * * copies and that both the copyright notice and this permission * * notice appear in supporting documentation, and that the name * * University of Delaware not be used in advertising or publicity * * pertaining to distribution of the software without specific, * * written prior permission. The University of Delaware makes no * * representations about the suitability this software for any * * purpose. It is provided "as is" without express or implied * * warranty. * * * *********************************************************************** </pre>
+<p>The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.</p>
<ol>
- <li
class="inline"><a href="mailto:%20takao_abe@xurb.jp">Takao Abe <takao_abe@xurb.jp></a> Clock driver for JJY receivers</li>
- <li
class="inline"><a href="mailto:%20mark_andrews@isc.org">Mark Andrews <mark_andrews@isc.org></a> Leitch atomic clock controller</li>
- <li
class="inline"><a href="mailto:%20altmeier@atlsoft.de">Bernd Altmeier <altmeier@atlsoft.de></a> hopf Elektronik serial line and PCI-bus devices</li>
- <li
class="inline"><a href="mailto:%20vbais@mailman1.intel.co">Viraj Bais <vbais@mailman1.intel.com></a> and <a href="mailto:%20kirkwood@striderfm.intel.com">Clayton Kirkwood <kirkwood@striderfm.intel.com></a> port to WindowsNT 3.5</li>
- <li
class="inline"><a href="mailto:%20michael.barone@lmco.com">Michael Barone <michael,barone@lmco.com></a> GPSVME fixes</li>
- <li
class="inline"><a href="mailto:%20karl@owl.HQ.ileaf.com">Karl Berry <karl@owl.HQ.ileaf.com></a> syslog to file option</li>
- <li
class="inline"><a href="mailto:%20greg.brackley@bigfoot.com">Greg Brackley <greg.brackley@bigfoot.com></a> Major rework of WINNT port. Clean up recvbuf and iosignal code into separate modules.</li>
- <li
class="inline"><a href="mailto:%20Marc.Brett@westgeo.com">Marc Brett <Marc.Brett@westgeo.com></a> Magnavox GPS clock driver</li>
- <li
class="inline"><a href="mailto:%20Piete.Brooks@cl.cam.ac.uk">Piete Brooks <Piete.Brooks@cl.cam.ac.uk></a> MSF clock driver, Trimble PARSE support</li>
- <li
class="inline"><a href="mailto:%20nelson@bolyard.me">Nelson B Bolyard <nelson@bolyard.me></a> update and complete broadcast and crypto features in sntp</li>
- <li
class="inline"><a href="mailto:%20Jean-Francois.Boudreault@viagenie.qc.ca">Jean-Francois Boudreault <Jean-Francois.Boudreault@viagenie.qc.ca></a> IPv6 support</li>
- <li
class="inline"><a href="mailto:%20reg@dwf.com">Reg Clemens <reg@dwf.com></a> Oncore driver (Current maintainer)</li>
- <li
class="inline"><a href="mailto:%20clift@ml.csiro.au">Steve Clift <clift@ml.csiro.au></a> OMEGA clock driver</li>
- <li
class="inline"><a href="mailto:casey@csc.co.za">Casey Crellin <casey@csc.co.za></a> vxWorks (Tornado) port and help with target configuration</li>
- <li
class="inline"><a href="mailto:%20Sven_Dietrich@trimble.COM">Sven Dietrich <sven_dietrich@trimble.com></a> Palisade reference clock driver, NT adj. residuals, integrated Greg's Winnt port.</li>
- <li
class="inline"><a href="mailto:%20dundas@salt.jpl.nasa.gov">John A. Dundas III <dundas@salt.jpl.nasa.gov></a> Apple A/UX port</li>
- <li
class="inline"><a href="mailto:%20duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe <duwe@immd4.informatik.uni-erlangen.de></a> Linux port</li>
- <li
class="inline"><a href="mailto:%20dennis@mrbill.canet.ca">Dennis Ferguson <dennis@mrbill.canet.ca></a> foundation code for NTP Version 2 as specified in RFC-1119</li>
- <li
class="inline"><a href="mailto:%20jhay@icomtek.csir.co.za">John Hay <jhay@icomtek.csir.co.za></a> IPv6 support and testing</li>
- <li
class="inline"><a href="mailto:%20davehart@davehart.com">Dave Hart <davehart@davehart.com></a> General maintenance, Windows port interpolation rewrite</li>
- <li
class="inline"><a href="mailto:%20neoclock4x@linum.com">Claas Hilbrecht <neoclock4x@linum.com></a> NeoClock4X clock driver</li>
- <li
class="inline"><a href="mailto:%20glenn@herald.usask.ca">Glenn Hollinger <glenn@herald.usask.ca></a> GOES clock driver</li>
- <li
class="inline"><a href="mailto:%20iglesias@uci.edu">Mike Iglesias <iglesias@uci.edu></a> DEC Alpha port</li>
- <li
class="inline"><a href="mailto:%20jagubox.gsfc.nasa.gov">Jim Jagielski <jim@jagubox.gsfc.nasa.gov></a> A/UX port</li>
- <li
class="inline"><a href="mailto:%20jbj@chatham.usdesign.com">Jeff Johnson <jbj@chatham.usdesign.com></a> massive prototyping overhaul</li>
- <li
class="inline"><a href="mailto:Hans.Lambermont@nl.origin-it.com">Hans Lambermont <Hans.Lambermont@nl.origin-it.com></a> or <a href="mailto:H.Lambermont@chello.nl"><H.Lambermont@chello.nl></a> ntpsweep</li>
- <li
class="inline"><a href="mailto:%20phk@FreeBSD.ORG">Poul-Henning Kamp <phk@FreeBSD.ORG></a> Oncore driver (Original author)</li>
- <li class="inline"><a href="http://www4.informatik.uni-erlangen.de/%7ekardel">Frank Kardel</a> <a href="mailto:%20kardel (at) ntp (dot) org"><kardel (at) ntp (dot) org></a> PARSE <GENERIC> (driver 14 reference clocks), STREAMS modules for PARSE, support scripts, syslog cleanup, dynamic interface handling</li>
- <li
class="inline"><a href="mailto:%20jones@hermes.chpc.utexas.edu">William L. Jones <jones@hermes.chpc.utexas.edu></a> RS/6000 AIX modifications, HPUX modifications</li>
- <li
class="inline"><a href="mailto:%20dkatz@cisco.com">Dave Katz <dkatz@cisco.com></a> RS/6000 AIX port</li>
- <li
class="inline"><a href="mailto:%20leres@ee.lbl.gov">Craig Leres <leres@ee.lbl.gov></a> 4.4BSD port, ppsclock, Magnavox GPS clock driver</li>
- <li
class="inline"><a href="mailto:%20lindholm@ucs.ubc.ca">George Lindholm <lindholm@ucs.ubc.ca></a> SunOS 5.1 port</li>
- <li
class="inline"><a href="mailto:%20louie@ni.umd.edu">Louis A. Mamakos <louie@ni.umd.edu></a> MD5-based authentication</li>
- <li
class="inline"><a href="mailto:%20thorinn@diku.dk">Lars H. Mathiesen <thorinn@diku.dk></a> adaptation of foundation code for Version 3 as specified in RFC-1305</li>
- <li
class="inline"><a href="mailto:%20mayer@ntp.org">Danny Mayer <mayer@ntp.org></a>Network I/O, Windows Port, Code Maintenance</li>
- <li
class="inline"><a href="mailto:%20mills@udel.edu">David L. Mills <mills@udel.edu></a> Version 4 foundation, precision kernel; clock drivers: 1, 3, 4, 6, 7, 11, 13, 18, 19, 22, 36</li>
- <li
class="inline"><a href="mailto:%20moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de></a> VMS port</li>
- <li
class="inline"><a href="mailto:%20mogul@pa.dec.com">Jeffrey Mogul <mogul@pa.dec.com></a> ntptrace utility</li>
- <li
class="inline"><a href="mailto:%20tmoore@fievel.daytonoh.ncr.com">Tom Moore <tmoore@fievel.daytonoh.ncr.com></a> i386 svr4 port</li>
- <li
class="inline"><a href="mailto:%20kamal@whence.com">Kamal A Mostafa <kamal@whence.com></a> SCO OpenServer port</li>
- <li
class="inline"><a href="mailto:%20derek@toybox.demon.co.uk">Derek Mulcahy <derek@toybox.demon.co.uk></a> and <a href="mailto:%20d@hd.org">Damon Hart-Davis <d@hd.org></a> ARCRON MSF clock driver</li>
- <li
class="inline"><a href="mailto:%20neal@ntp.org">Rob Neal <neal@ntp.org></a> Bancomm refclock and config/parse code maintenance</li>
- <li
class="inline"><a href="mailto:%20Rainer.Pruy@informatik.uni-erlangen.de">Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de></a> monitoring/trap scripts, statistics file handling</li>
- <li
class="inline"><a href="mailto:%20dirce@zk3.dec.com">Dirce Richards <dirce@zk3.dec.com></a> Digital UNIX V4.0 port</li>
- <li
class="inline"><a href="mailto:%20wsanchez@apple.com">Wilfredo Sánchez <wsanchez@apple.com></a> added support for NetInfo</li>
- <li
class="inline"><a href="mailto:%20mrapple@quack.kfu.com">Nick Sayer <mrapple@quack.kfu.com></a> SunOS streams modules</li>
- <li
class="inline"><a href="mailto:%20jack@innovativeinternet.com">Jack Sasportas <jack@innovativeinternet.com></a> Saved a Lot of space on the stuff in the html/pic/ subdirectory</li>
- <li
class="inline"><a href="mailto:%20schnitz@unipress.com">Ray Schnitzler <schnitz@unipress.com></a> Unixware1 port</li>
- <li
class="inline"><a href="mailto:%20shields@tembel.org">Michael Shields <shields@tembel.org></a> USNO clock driver</li>
- <li
class="inline"><a href="mailto:%20pebbles.jpl.nasa.gov">Jeff Steinman <jss@pebbles.jpl.nasa.gov></a> Datum PTS clock driver</li>
- <li
class="inline"><a href="mailto:%20harlan@pfcs.com">Harlan Stenn <harlan@pfcs.com></a> GNU automake/autoconfigure makeover, various other bits (see the ChangeLog)</li>
- <li
class="inline"><a href="mailto:%20ken@sdd.hp.com">Kenneth Stone <ken@sdd.hp.com></a> HP-UX port</li>
- <li
class="inline"><a href="mailto:%20ajit@ee.udel.edu">Ajit Thyagarajan <ajit@ee.udel.edu></a>IP multicast/anycast support</li>
- <li
class="inline"><a href="mailto:%20tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp></a>TRAK clock driver</li>
- <li
class="inline"><a href="mailto:%20vixie@vix.com">Paul A Vixie <vixie@vix.com></a> TrueTime GPS driver, generic TrueTime clock driver</li>
- <li
class="inline"><a href="mailto:%20Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de></a> corrected and validated HTML documents according to the HTML DTD</li>
+ <li><a href="mailto:%20takao_abe@xurb.jp">Takao Abe <takao_abe@xurb.jp></a> Clock driver for JJY receivers</li>
+ <li><a href="mailto:%20mark_andrews@isc.org">Mark Andrews <mark_andrews@isc.org></a> Leitch atomic clock controller</li>
+ <li><a href="mailto:%20altmeier@atlsoft.de">Bernd Altmeier <altmeier@atlsoft.de></a> hopf Elektronik serial line and PCI-bus devices</li>
+ <li><a href="mailto:%20vbais@mailman1.intel.co">Viraj Bais <vbais@mailman1.intel.com></a> and <a href="mailto:%20kirkwood@striderfm.intel.com">Clayton Kirkwood <kirkwood@striderfm.intel.com></a> port to WindowsNT 3.5</li>
+ <li><a href="mailto:%20michael.barone@lmco.com">Michael Barone <michael,barone@lmco.com></a> GPSVME fixes</li>
+ <li><a href="mailto:%20karl@owl.HQ.ileaf.com">Karl Berry <karl@owl.HQ.ileaf.com></a> syslog to file option</li>
+ <li><a href="mailto:%20greg.brackley@bigfoot.com">Greg Brackley <greg.brackley@bigfoot.com></a> Major rework of WINNT port. Clean up recvbuf and iosignal code into separate modules.</li>
+ <li><a href="mailto:%20Marc.Brett@westgeo.com">Marc Brett <Marc.Brett@westgeo.com></a> Magnavox GPS clock driver</li>
+ <li><a href="mailto:%20Piete.Brooks@cl.cam.ac.uk">Piete Brooks <Piete.Brooks@cl.cam.ac.uk></a> MSF clock driver, Trimble PARSE support</li>
+ <li><a href="mailto:%20nelson@bolyard.me">Nelson B Bolyard <nelson@bolyard.me></a> update and complete broadcast and crypto features in sntp</li>
+ <li><a href="mailto:%20Jean-Francois.Boudreault@viagenie.qc.ca">Jean-Francois Boudreault <Jean-Francois.Boudreault@viagenie.qc.ca></a> IPv6 support</li>
+ <li><a href="mailto:%20reg@dwf.com">Reg Clemens <reg@dwf.com></a> Oncore driver (Current maintainer)</li>
+ <li><a href="mailto:%20clift@ml.csiro.au">Steve Clift <clift@ml.csiro.au></a> OMEGA clock driver</li>
+ <li><a href="mailto:casey@csc.co.za">Casey Crellin <casey@csc.co.za></a> vxWorks (Tornado) port and help with target configuration</li>
+ <li><a href="mailto:%20Sven_Dietrich@trimble.COM">Sven Dietrich <sven_dietrich@trimble.com></a> Palisade reference clock driver, NT adj. residuals, integrated Greg's Winnt port.</li>
+ <li><a href="mailto:%20dundas@salt.jpl.nasa.gov">John A. Dundas III <dundas@salt.jpl.nasa.gov></a> Apple A/UX port</li>
+ <li><a href="mailto:%20duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe <duwe@immd4.informatik.uni-erlangen.de></a> Linux port</li>
+ <li><a href="mailto:%20dennis@mrbill.canet.ca">Dennis Ferguson <dennis@mrbill.canet.ca></a> foundation code for NTP Version 2 as specified in RFC-1119</li>
+ <li><a href="mailto:%20jhay@icomtek.csir.co.za">John Hay <jhay@icomtek.csir.co.za></a> IPv6 support and testing</li>
+ <li><a href="mailto:%20davehart@davehart.com">Dave Hart <davehart@davehart.com></a> General maintenance, Windows port interpolation rewrite</li>
+ <li><a href="mailto:%20neoclock4x@linum.com">Claas Hilbrecht <neoclock4x@linum.com></a> NeoClock4X clock driver</li>
+ <li><a href="mailto:%20glenn@herald.usask.ca">Glenn Hollinger <glenn@herald.usask.ca></a> GOES clock driver</li>
+ <li><a href="mailto:%20iglesias@uci.edu">Mike Iglesias <iglesias@uci.edu></a> DEC Alpha port</li>
+ <li><a href="mailto:%20jagubox.gsfc.nasa.gov">Jim Jagielski <jim@jagubox.gsfc.nasa.gov></a> A/UX port</li>
+ <li><a href="mailto:%20jbj@chatham.usdesign.com">Jeff Johnson <jbj@chatham.usdesign.com></a> massive prototyping overhaul</li>
+ <li><a href="mailto:Hans.Lambermont@nl.origin-it.com">Hans Lambermont <Hans.Lambermont@nl.origin-it.com></a> or <a href="mailto:H.Lambermont@chello.nl"><H.Lambermont@chello.nl></a> ntpsweep</li>
+ <li><a href="mailto:%20phk@FreeBSD.ORG">Poul-Henning Kamp <phk@FreeBSD.ORG></a> Oncore driver (Original author)</li>
+ <li><a href="http://www4.informatik.uni-erlangen.de/%7ekardel">Frank Kardel</a> <a href="mailto:%20kardel%20%28at%29%20ntp%20%28dot%29%20org"><kardel (at) ntp (dot) org></a> PARSE <GENERIC> (driver 14 reference clocks), STREAMS modules for PARSE, support scripts, syslog cleanup, dynamic interface handling</li>
+ <li><a href="mailto:%20jones@hermes.chpc.utexas.edu">William L. Jones <jones@hermes.chpc.utexas.edu></a> RS/6000 AIX modifications, HPUX modifications</li>
+ <li><a href="mailto:%20dkatz@cisco.com">Dave Katz <dkatz@cisco.com></a> RS/6000 AIX port</li>
+ <li><a href="mailto:%20leres@ee.lbl.gov">Craig Leres <leres@ee.lbl.gov></a> 4.4BSD port, ppsclock, Magnavox GPS clock driver</li>
+ <li><a href="mailto:%20lindholm@ucs.ubc.ca">George Lindholm <lindholm@ucs.ubc.ca></a> SunOS 5.1 port</li>
+ <li><a href="mailto:%20louie@ni.umd.edu">Louis A. Mamakos <louie@ni.umd.edu></a> MD5-based authentication</li>
+ <li><a href="mailto:%20thorinn@diku.dk">Lars H. Mathiesen <thorinn@diku.dk></a> adaptation of foundation code for Version 3 as specified in RFC-1305</li>
+ <li><a href="mailto:%20mayer@ntp.org">Danny Mayer <mayer@ntp.org></a>Network I/O, Windows Port, Code Maintenance</li>
+ <li><a href="mailto:%20mills@udel.edu">David L. Mills <mills@udel.edu></a> Version 4 foundation, precision kernel; clock drivers: 1, 3, 4, 6, 7, 11, 13, 18, 19, 22, 36</li>
+ <li><a href="mailto:%20moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de></a> VMS port</li>
+ <li><a href="mailto:%20mogul@pa.dec.com">Jeffrey Mogul <mogul@pa.dec.com></a> ntptrace utility</li>
+ <li><a href="mailto:%20tmoore@fievel.daytonoh.ncr.com">Tom Moore <tmoore@fievel.daytonoh.ncr.com></a> i386 svr4 port</li>
+ <li><a href="mailto:%20kamal@whence.com">Kamal A Mostafa <kamal@whence.com></a> SCO OpenServer port</li>
+ <li><a href="mailto:%20derek@toybox.demon.co.uk">Derek Mulcahy <derek@toybox.demon.co.uk></a> and <a href="mailto:%20d@hd.org">Damon Hart-Davis <d@hd.org></a> ARCRON MSF clock driver</li>
+ <li><a href="mailto:%20neal@ntp.org">Rob Neal <neal@ntp.org></a> Bancomm refclock and config/parse code maintenance</li>
+ <li><a href="mailto:%20Rainer.Pruy@informatik.uni-erlangen.de">Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de></a> monitoring/trap scripts, statistics file handling</li>
+ <li><a href="mailto:%20dirce@zk3.dec.com">Dirce Richards <dirce@zk3.dec.com></a> Digital UNIX V4.0 port</li>
+ <li><a href="mailto:%20wsanchez@apple.com">Wilfredo Sánchez <wsanchez@apple.com></a> added support for NetInfo</li>
+ <li><a href="mailto:%20mrapple@quack.kfu.com">Nick Sayer <mrapple@quack.kfu.com></a> SunOS streams modules</li>
+ <li><a href="mailto:%20jack@innovativeinternet.com">Jack Sasportas <jack@innovativeinternet.com></a> Saved a Lot of space on the stuff in the html/pic/ subdirectory</li>
+ <li><a href="mailto:%20schnitz@unipress.com">Ray Schnitzler <schnitz@unipress.com></a> Unixware1 port</li>
+ <li><a href="mailto:%20shields@tembel.org">Michael Shields <shields@tembel.org></a> USNO clock driver</li>
+ <li><a href="mailto:%20pebbles.jpl.nasa.gov">Jeff Steinman <jss@pebbles.jpl.nasa.gov></a> Datum PTS clock driver</li>
+ <li><a href="mailto:%20harlan@pfcs.com">Harlan Stenn <harlan@pfcs.com></a> GNU automake/autoconfigure makeover, various other bits (see the ChangeLog)</li>
+ <li><a href="mailto:%20ken@sdd.hp.com">Kenneth Stone <ken@sdd.hp.com></a> HP-UX port</li>
+ <li><a href="mailto:%20ajit@ee.udel.edu">Ajit Thyagarajan <ajit@ee.udel.edu></a>IP multicast/anycast support</li>
+ <li><a href="mailto:%20tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp></a>TRAK clock driver</li>
+ <li><a href="mailto:%20vixie@vix.com">Paul A Vixie <vixie@vix.com></a> TrueTime GPS driver, generic TrueTime clock driver</li>
+ <li><a href="mailto:%20Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de></a> corrected and validated HTML documents according to the HTML DTD</li>
</ol>
<hr>
-<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</head>
<body>
- <h3>Generic Reference Driver</h3>
- <hr>
- <h4>Synopsis</h4>
- Address: 127.127.8.<i>u</i><br>
- Reference ID: <tt>PARSE</tt><br>
- Driver ID: <tt>GENERIC</tt><br>
- Serial Port: <tt>/dev/refclock-<i>u</i></tt>; TTY mode according to clock type<br>
- PPS device: <tt>/dev/refclockpps-<i>u</i></tt>; alternate PPS device (if not available via the serial port)
- <h4>Description</h4>
- The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br>
- <br>
- <p>The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see <a href="#clocklist">list below</a>).</p>
- <p>The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p>
- <p>CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.</p>
- <p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p>
- <h4>Timecode variables listed by ntpq (8)</h4>
- <p>The ntpq program can read and display several clock variables. These hold the following information:</p>
- <dl>
- <dt><tt>refclock_format</tt></dt>
- <dd>A qualification of the decoded time code format.</dd>
- <dt><tt>refclock_states</tt></dt>
- <dd>The overall running time and the accumulated times for the clock event states.</dd>
- <dt><tt>refclock_status</tt></dt>
- <dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd>
- <dt><tt>refclock_time</tt></dt>
- <dd>The local time with the offset to UTC (format HHMM).</dd>
- <dt><tt>timecode</tt></dt>
- <dd>The actual time code.</dd>
- </dl>
- <p>If PPS information is present, additional variables are available:</p>
- <dl>
- <dt><tt>refclock_ppsskew</tt></dt>
- <dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd>
- <dt><tt>refclock_ppstime</tt></dt>
- <dd>The PPS timestamp.</dd>
- </dl>
- <h4>Supported Devices</h4>
- <p>Currently, nineteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver.<br>
- A note on the implementations:</p>
- <ul>
- <li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel <AT> ntp.org">kardel <AT> ntp.org</a>) are welcome as long as they work within Europe 8-).
- <p>Verified implementations are:</p>
- <ul>
- <li>RAWDCF variants
- <p>These variants have been tested for correct decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p>
- <li><a href="http://www.meinberg.de">Meinberg clocks</a>
- <p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p>
- </ul>
- </ul>
- <p>The pictures below have been taken from and are linked to the vendors' web pages.</p>
- <a name="clocklist"></a>
- <ul>
- <li><b><tt>server 127.127.8.0-3 mode 0</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50μs)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 1</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50μs)</tt></b><br>
- <a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" height="300" width="260" align="top" border="0"></a><br>
- <br></p>
-
- <li><a name="mode2"></a><b><tt>server 127.127.8.0-3 mode 2</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</tt></b><br>
- <a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" height="239" width="330" align="top" border="0"></a><br>
- </p>
- <p>This mode expects the Meinberg standard time string format with 9600/7E2.</p>
- <p><b>Note:</b> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 3</tt></b>
- <p><b><tt><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 4</tt></b>
- <p><b><tt>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 5</tt></b>
- <p><b><tt>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 6</tt></b>
- <p><b><tt>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 7</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</tt></b><br>
- <a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" height="300" width="280" align="top" border="0"></a><br>
- </p>
- <p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p>
- <p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p>
- <p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p>
- <p><b>Note:</b> mode 7 must not be used with Meinberg PCI cards; use <a href="#mode2">mode 2</a> instead.<br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 8</tt></b>
- <p><b><tt><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></tt></b><br>
- <a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" height="174" width="200" border="0"></a><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 9</tt></b>
- <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / <<1μs)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 10</tt></b>
- <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1μs) (no kernel support yet)</tt></b><br>
- <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" height="100" width="420" align="top" border="0"></a><br>
- <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" height="100" width="420" border="0"></a><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 11</tt></b>
- <p><b><tt>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 12</tt></b>
- <p><b><tt><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></tt></b><br>
- <a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" height="207" width="238" align="top" border="0"></a><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 13</tt></b>
- <p><b><tt>Diem's Computime Radio Clock</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 14</tt></b>
- <p><b><tt>RAWDCF receiver (DTR=high/RTS=low)</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 15</tt></b>
- <p><b><tt>WHARTON 400A Series Clocks with a 404.2 Serial Interface</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 16</tt></b>
- <p><b><tt>RAWDCF receiver (DTR=low/RTS=high) </tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 17</tt></b>
- <p><b><tt>VARITEXT Receiver (MSF) </tt></b><br>
- <br></p>
-
- <li><a name="mode18"></a><b><tt>server 127.127.8.0-3 mode 18</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</tt></b><br>
- </p>
- <p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p>
- <p><b>Note:</b> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br>
- <br></p>
- <li><b><tt>server 127.127.8.0-3 mode 19</tt></b>
- <p><b><tt>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</tt></b><br>
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 20</tt></b>
- <p><b><tt>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</tt></b><br>
- </p>
- <p>Driving the DCF clocks at 75 baud may help to get them to work with a bunch of common USB serial converters, that do 75 but cannot do 50 baud at all, e.g. those based on Prolific PL2303.
- <br></p>
-
- <li><b><tt>server 127.127.8.0-3 mode 21</tt></b>
- <p><b><tt>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </tt></b><br>
- </p>
- <p>See comment from mode 20 clock.
- <br></p>
-
- </ul>
- <p>Actual data formats and setup requirements of the various clocks can be found in <a href="../parsedata.html">NTP PARSE clock data formats</a>.</p>
- <h4>Operation</h4>
- <p>The reference clock support software carefully monitors the state transitions of the receiver. All state changes and exceptional events (such as loss of time code transmission) are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog.</p>
- <p>PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.</p>
- <p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Synchronization ceases when reception of the DCF77 signal deteriorates, since no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p>
- <p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used.
- </p>
- <h4>Hardware PPS support<br>
- </h4>
- <p>For PPS to be used, add 128 to the mode parameter.</p>
- <p>If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.</p>
- <h4>Monitor Data</h4>
- <p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the <code>ntpq cv</code> command.<br>
- Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data
- and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on
- a specific clock association as shown below.
- </p>
- <p>First let <code>ntpq</code> display the table of associations:</p>
- <pre>
- ntpq> as
- ind assID status conf reach auth condition last_event cnt
- ===========================================================
- 1 19556 9154 yes yes none falsetick reachable 5
- 2 19557 9435 yes yes none candidat clock expt 3
- 3 19558 9714 yes yes none pps.peer reachable 1
- </pre>
- <p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p>
- <pre>
- ntpq> raw
- Output set to raw
- </pre>
- <p>Use the cv command to read the list of clock variables of a selected association:</p>
- <pre>
- ntpq> cv 19557 clock_var_list
- </pre>
- <p>The long output of the command above looks similar to:</p>
- <pre>
- assID=19557 status=0x0000,
- clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1,
- fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status,
- refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version,
- meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51,
- gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],
- gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]"
- </pre>
- <p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p>
- <pre>
- ntpq> cv 19557 refclock_status,refclock_format,refclock_states,refclock_id,
- refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction,
- gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1],
- gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4],
- gps_health[4],gps_cfg[5]
- </pre>
- <p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p>
- <pre>
- status=0x0003,
- refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION;
- PPS SIGNAL; POSITION)",
- refclock_format="Meinberg GPS Extended",
- refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%);
- running time: 21:21:39",
- refclock_id="GPS", refclock_iomode="normal",
- refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49
- kardel RELEASE_20060805_A",
- meinberg_gps_status="[0x0000] <OK>",
- gps_utc_correction="current correction 14 sec, last correction
- on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000",
- gps_message="/PFU3SOP-4WG14EPU0V1KA",
- meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000)
- UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s,
- disconnect time 0000-00-00 00:00:00.0000000 (+0000) ",
- gps_tot_51="week 1400 + 3 days + 42300.0000000 sec",
- gps_tot_63="week 1400 + 3 days + 42294.0000000 sec",
- gps_t0a="week 1400 + 5 days + 71808.0000000 sec",
- gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK",
- gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS",
- gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK",
- gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK",
- gps_cfg[5]="[0x9] BLOCK II"
- </pre>
- <h4>Fudge Factors</h4>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type.
- <dt><tt>time2 <i>time</i></tt>
- <dd>
- If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning).
- <dd>
- If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation.
- <dt><tt>stratum <i>stratum</i></tt>
- <dd>The stratum for this reference clock.
- <dt><tt>refid <i>refid</i></tt>
- <dd>The refid for this reference clock.
- </dl>
- <dl>
- <dt><tt>flag1 { 0 | 1 }</tt>
- <dd>If 0, the fudge factor <tt>time2</tt> refers to the PPS offset.
- <dd>If 1, <tt>time2</tt> refers to the TRUST TIME.
- <dt><tt>flag2 { 0 | 1 }</tt>
- <dd>If <tt>flag2</tt> is 1, sample PPS on CLEAR instead of on ASSERT.
- <dt><tt>flag3 { 0 | 1 }</tt>
- <dd>If <tt>flag3</tt> is 1, link kernel PPS tracking to this refclock instance.
- <dt><tt>flag4 { 0 | 1 }</tt>
- <dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-)
- </dl>
- <span style="font-weight: bold;">Note about auxiliary Sun STREAMS modules (SunOS and Solaris):</span><br>
- <dl>
- <dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used.
- </dl>
- <h4>Making your own PARSE clocks</h4>
- <p>The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p>
- <p>Additional Information</p>
- <p><a href="../refclock.html">Reference Clock Drivers</a></p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ <h3>Generic Reference Driver</h3>
+ <hr>
+ <h4>Synopsis</h4>
+ Address: 127.127.8.<em>u</em><br>
+Reference ID: PARSE<br>
+Driver ID: GENERIC<br>
+Serial Port: /dev/refclock-<em>u</em>; TTY mode according to clock type<br>
+PPS device: /dev/refclockpps-<em>u</em>; alternate PPS device (if not available via the serial port)
+<h4>Description</h4>
+The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br>
+<br>
+<p>The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#clocklist">list below</a>).</p>
+<p>The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p>
+<p>CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.</p>
+<p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p>
+<h4>Timecode variables listed by ntpq (8)</h4>
+<p>The ntpq program can read and display several clock variables. These hold the following information:</p>
+<dl>
+ <dt>refclock_format</dt>
+ <dd>A qualification of the decoded time code format.</dd>
+ <dt>refclock_states</dt>
+ <dd>The overall running time and the accumulated times for the clock event states.</dd>
+ <dt>refclock_status</dt>
+ <dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd>
+ <dt>refclock_time</dt>
+ <dd>The local time with the offset to UTC (format HHMM).</dd>
+ <dt>timecode</dt>
+ <dd>The actual time code.</dd>
+</dl>
+<p>If PPS information is present, additional variables are available:</p>
+<dl>
+ <dt>refclock_ppsskew</dt>
+ <dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd>
+ <dt>refclock_ppstime</dt>
+ <dd>The PPS timestamp.</dd>
+</dl>
+<h4>Supported Devices</h4>
+<p>Currently, nineteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver.<br>
+ A note on the implementations:</p>
+<ul>
+ <li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel%20%3CAT%3E%20ntp.org">kardel <AT> ntp.org</a>) are welcome as long as they work within Europe 8-).
+ <p>Verified implementations are:</p>
+ <ul>
+ <li>RAWDCF variants
+ <p>These variants have been tested for correct decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p>
+ </li>
+ <li><a href="http://www.meinberg.de">Meinberg clocks</a>
+ <p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p>
+ </li>
+ </ul>
+ </li>
+</ul>
+<p>The pictures below have been taken from and are linked to the vendors' web pages.</p>
+<a name="clocklist"></a>
+<ul>
+ <li><strong>server 127.127.8.0-3 mode 0</strong>
+ <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50μs)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 1</strong>
+ <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50μs)</strong><br>
+ <a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" align="top" border="0" height="300" width="260"></a><br>
+ <br>
+ </p>
+ </li>
+ <li><a name="mode2"></a><strong>server 127.127.8.0-3 mode 2</strong>
+ <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</strong><br>
+ <a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" align="top" border="0" height="239" width="330"></a><br>
+ </p>
+ <p>This mode expects the Meinberg standard time string format with 9600/7E2.</p>
+ <p><strong>Note:</strong> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 3</strong>
+ <p><strong><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 4</strong>
+ <p><strong>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 5</strong>
+ <p><strong>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 6</strong>
+ <p><strong>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 7</strong>
+ <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</strong><br>
+ <a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" align="top" border="0" height="300" width="280"></a><br>
+ </p>
+ <p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p>
+ <p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p>
+ <p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p>
+ <p><strong>Note:</strong> mode 7 must not be used with Meinberg PCI cards; use <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode2">mode 2</a> instead.<br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 8</strong>
+ <p><strong><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></strong><br>
+ <a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" border="0" height="174" width="200"></a><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 9</strong>
+ <p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / <<1μs)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 10</strong>
+ <p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1μs) (no kernel support yet)</strong><br>
+ <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" align="top" border="0" height="100" width="420"></a><br>
+ <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" border="0" height="100" width="420"></a><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 11</strong>
+ <p><strong>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 12</strong>
+ <p><strong><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></strong><br>
+ <a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" align="top" border="0" height="207" width="238"></a><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 13</strong>
+ <p><strong>Diem's Computime Radio Clock</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 14</strong>
+ <p><strong>RAWDCF receiver (DTR=high/RTS=low)</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 15</strong>
+ <p><strong>WHARTON 400A Series Clocks with a 404.2 Serial Interface</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 16</strong>
+ <p><strong>RAWDCF receiver (DTR=low/RTS=high) </strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 17</strong>
+ <p><strong>VARITEXT Receiver (MSF) </strong><br>
+ <br>
+ </p>
+ </li>
+ <li><a name="mode18"></a><strong>server 127.127.8.0-3 mode 18</strong>
+ <p><strong><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</strong><br>
+ </p>
+ <p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p>
+ <p><strong>Note:</strong> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 19</strong>
+ <p><strong>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</strong><br>
+ <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 20</strong>
+ <p><strong>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</strong><br>
+ </p>
+ <p>Driving the DCF clocks at 75 baud may help to get them to work with a bunch of common USB serial converters, that do 75 but cannot do 50 baud at all, e.g. those based on Prolific PL2303. <br>
+ </p>
+ </li>
+ <li><strong>server 127.127.8.0-3 mode 21</strong>
+ <p><strong>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </strong><br>
+ </p>
+ <p>See comment from mode 20 clock. <br>
+ </p>
+ </li>
+</ul>
+<p>Actual data formats and setup requirements of the various clocks can be found in <a href="../parsedata.html">NTP PARSE clock data formats</a>.</p>
+<h4>Operation</h4>
+<p>The reference clock support software carefully monitors the state transitions of the receiver. All state changes and exceptional events (such as loss of time code transmission) are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog.</p>
+<p>PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.</p>
+<p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Synchronization ceases when reception of the DCF77 signal deteriorates, since no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p>
+<p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used. </p>
+<h4>Hardware PPS support<br>
+</h4>
+<p>For PPS to be used, add 128 to the mode parameter.</p>
+<p>If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.</p>
+<h4>Monitor Data</h4>
+<p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the ntpq cv command.<br>
+ Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on a specific clock association as shown below. </p>
+<p>First let ntpq display the table of associations:</p>
+<pre> ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 19556 9154 yes yes none falsetick reachable 5 2 19557 9435 yes yes none candidat clock expt 3 3 19558 9714 yes yes none pps.peer reachable 1 </pre>
+<p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p>
+<pre> ntpq> raw Output set to raw </pre>
+<p>Use the cv command to read the list of clock variables of a selected association:</p>
+<pre> ntpq> cv 19557 clock_var_list </pre>
+<p>The long output of the command above looks similar to:</p>
+<pre> assID=19557 status=0x0000, clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1, fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status, refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version, meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51, gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3], gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]" </pre>
+<p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p>
+<pre> ntpq> cv 19557 refclock_status,refclock_format,refclock_states,refclock_id, refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction, gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1], gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4], gps_health[4],gps_cfg[5] </pre>
+<p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p>
+<pre> status=0x0003, refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION)", refclock_format="Meinberg GPS Extended", refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%); running time: 21:21:39", refclock_id="GPS", refclock_iomode="normal", refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49 kardel RELEASE_20060805_A", meinberg_gps_status="[0x0000] <OK>", gps_utc_correction="current correction 14 sec, last correction on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000", gps_message="/PFU3SOP-4WG14EPU0V1KA", meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000) UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s, disconnect time 0000-00-00 00:00:00.0000000 (+0000) ", gps_tot_51="week 1400 + 3 days + 42300.0000000 sec", gps_tot_63="week 1400 + 3 days + 42294.0000000 sec", gps_t0a="week 1400 + 5 days + 71808.0000000 sec", gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK", gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS", gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK", gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK", gps_cfg[5]="[0x9] BLOCK II" </pre>
+<h4>Fudge Factors</h4>
+<dl>
+ <dt>time1 <em>time</em> </dt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type. </dd>
+ <dt>time2 <em>time</em> </dt>
+ <dd> If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning). </dd>
+ <dd> If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation. </dd>
+ <dt>stratum <em>stratum</em> </dt>
+ <dd>The stratum for this reference clock. </dd>
+ <dt>refid <em>refid</em> </dt>
+ <dd>The refid for this reference clock. </dd>
+</dl>
+<dl>
+ <dt>flag1 { 0 | 1 } </dt>
+ <dd>If 0, the fudge factor time2 refers to the PPS offset. </dd>
+ <dd>If 1, time2 refers to the TRUST TIME. </dd>
+ <dt>flag2 { 0 | 1 } </dt>
+ <dd>If flag2 is 1, sample PPS on CLEAR instead of on ASSERT. </dd>
+ <dt>flag3 { 0 | 1 } </dt>
+ <dd>If flag3 is 1, link kernel PPS tracking to this refclock instance. </dd>
+ <dt>flag4 { 0 | 1 } </dt>
+ <dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-) </dd>
+</dl>
+Note about auxiliary Sun STREAMS modules (SunOS and Solaris):<br>
+<dl>
+ <dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used. </dt>
+</dl>
+<h4>Making your own PARSE clocks</h4>
+<p>The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p>
+<p>Additional Information</p>
+<p><a href="../refclock.html">Reference Clock Drivers</a></p>
+<hr>
+ </body>
</html>
<p><img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a></p>
<p>Alice holds the key.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->13-Dec-2010 5:07<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Dec-2010 5:00<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
-l <em>days</em>] [ -m <i>modulus</i> ] [ -p <i>passwd1</i> ] [ -q <i>passwd2</i> ] [ -S
[ RSA | DSA ] ] [ -s <i>host</i> ] [ -V <i>nkeys</i> ]</tt></p>
<h4 id="descrip">Description</h4>
-<p>This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It can generate message digest keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it can generate host keys, sign keys, certificates and identity keys used by the Autokey public key cryptography. The message digest keys file is generated in a format compatible with NTPv3. All other files are in PEM-encoded printable ASCII format so they can be embedded as MIME attachments in mail to other sites.</p>
+<p>This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It can generate message digest keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it can generate host keys, sign keys, certificates, and identity keys and parameters used by the Autokey public key cryptography. The message digest keys file is generated in a format compatible with NTPv3. All other files are in PEM-encoded printable ASCII format so they can be embedded as MIME attachments in mail to other sites.</p>
<p>When used to generate message digest keys, the program produces a file containing
- ten pseudo-random printable ASCII strings suitable for the MD5 message digest algorithm included in the distribution. If the OpenSSL library is installed, it produces an additional ten hex-encoded random bit strings suitable for the SHA1 and other message digest algorithms.</p>
-<p>Message digest keys are specified in a keys file which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be defined as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.</p>
+ ten pseudo-random printable ASCII strings suitable for the MD5 message digest algorithm included in the distribution. If the OpenSSL library is installed, it produces an additional ten hex-encoded random bit strings suitable for the SHA1 and other message digest algorithms. The message digest keys file must be distributed and stored using secure means beyond the scope of NTP itself. Besides the keys used for ordinary NTP associations, additional keys can be defined as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.</p>
<p>The remaining generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program are compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.</p>
-<p>Some files used by this program are encrypted using a private password. The <tt>-p</tt> option specifies the password for local files and the <tt>-q</tt> option the password for encrypted files sent to remote sites. If no password is specified, the host name returned by the Unix <tt>gethostname()</tt> function, normally the DNS name of the host, is used.</p>
-<p>The <tt>pw</tt> option of the <tt>crypto</tt> configuration command specifies the read password for previously encrypted files. This must match the local password used by this program. If not specified, the host name is used. Thus, if files are generated by this program without password, they can be read back by <tt>ntpd</tt> without password, but only on the same host.</p>
-<p>Normally, encrypted files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page. The symmetric keys file, normally called <tt>ntp.keys</tt>, is usually installed in <tt>/etc</tt>. Other files and links are usually installed in <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks and cannot be changed by shared clients. The location of the keys directory can be changed by the <tt>keysdir</tt> configuration command in such cases.</p>
+<p>Some files used by this program are encrypted using a private password. The <tt>-p</tt> option specifies the password for local encrypted files and the <tt>-q</tt> option the password for encrypted files sent to remote sites. If no password is specified, the host name returned by the Unix <tt>gethostname()</tt> function, normally the DNS name of the host, is used.</p>
+<p>The <tt>pw</tt> option of the <tt>crypto</tt> configuration command specifies the read password for previously encrypted local files. This must match the local password used by this program. If not specified, the host name is used. Thus, if files are generated by this program without password, they can be read back by <tt>ntpd</tt> without password, but only on the same host.</p>
+<p>Normally, encrypted files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page. The symmetric keys file, normally called <tt>ntp.keys</tt>, is usually installed in <tt>/etc</tt>. Other files and links are usually installed in <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks and cannot be changed by shared clients. The location of the keys directory can be changed by the <tt>keysdir</tt> configuration command in such cases. Normally, this is in <tt>/etc</tt>.</p>
<p>This program directs commentary and error messages to the standard error stream <tt>stderr</tt> and remote files to the standard output stream <tt>stdout</tt> where they can be piped to other applications or redirected to files. The names used for generated files and links all begin with the string <tt>ntpkey</tt> and include the file type, generating host and filestamp, as described in the <a href="#fmt">Cryptographic Data Files</a> section below</p>
<h4 id="run">Running the Program</h4>
-<p>To test and gain experience with Autokey concepts, log in as root and change to the keys directory, usually <tt>/usr/local/etc</tt>. When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key and matching RSA-MD5 certificate with expiration date one year hence. If run again, the program uses the existing keys and parameters and generates only a new certificate with new expiration date one year hence.</p>
+<p>To test and gain experience with Autokey concepts, log in as root and change to the keys directory, usually <tt>/usr/local/etc</tt>. When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key and matching RSA-MD5 certificate with expiration date one year hence. If run again without options, the program uses the existing keys and parameters and generates only a new certificate with new expiration date one year hence.</p>
<p>Run the command on as many hosts as necessary. Designate one of them as the trusted host (TH) using <tt>ntp-keygen</tt> with the <tt>-T</tt> option and configure it to synchronize from reliable Internet servers. Then configure the other hosts to synchronize to the TH directly or indirectly. A certificate trail is created when Autokey asks the immediately ascendant host towards the TH to sign its certificate, which is then provided to the immediately descendant host on request. All group hosts should have acyclic certificate trails ending on the TH.</p>
<p>The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. A different sign key can be assigned using the <tt>-S</tt> option and this can be either RSA or DSA type. By default, the signature message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified using the <tt>-c</tt> option.</p>
-<dd>The rules say cryptographic media should be generated with proventic filestamps, which means the host should already be synchronized before this program is run. This of course creates a fowl problem when the host is started for the first time. Accordingly, the host time should be set by some other means, such as eyeball-and-wristwatch, at lest so that the certificate lifetime is within the current year. After that and when the host is synchronized to a proventic source, the certificate should be re-generated.</dd>
+<dd>The rules say cryptographic media should be generated with proventic filestamps, which means the host should already be synchronized before this program is run. This of course creates a chicken-and-egg problem when the host is started for the first time. Accordingly, the host time should be set by some other means, such as eyeball-and-wristwatch, at least so that the certificate lifetime is within the current year. After that and when the host is synchronized to a proventic source, the certificate should be re-generated.</dd>
<p>Additional information on trusted groups and identity schemes is on the <a href="autokey.html">Autokey Public-Key Authentication</a> page.</p>
<h4 id="cmd">Command Line Options</h4>
<dl>
<dt><tt>-T</tt></dt>
<dd>Generate a trusted certificate. By default, the program generates nontrusted certificates.</dd>
<dt><tt>-V <i>nkeys</i></tt></dt>
- <dd>Generate server parameters <tt></tt> keys for the Mu-Varadharajan (MV) identity scheme. This option is mutually exclusive with the <tt>-I</tt> and <tt>-G</tt> options. Note: support for this option should be considered a work in progress.</dd>
+ <dd>Generate <tt>nkeys</tt> encrypted server keys for the Mu-Varadharajan (MV) identity scheme. This option is mutually exclusive with the <tt>-I</tt> and <tt>-G</tt> options. Note: support for this option should be considered a work in progress.</dd>
</dl>
<h4 id="rand">Random Seed File</h4>
<p>All cryptographically sound key generation schemes must have means to randomize the entropy seed used to initialize the internal pseudo-random number generator used by the OpenSSL library routines. If a site supports <tt>ssh</tt>, it is very likely that means to do this are already available. The entropy seed used by the OpenSSL library is contained in a file, usually called <tt>.rnd</tt>, which must be available when starting the <tt>ntp-keygen</tt> program or <tt>ntpd</tt> daemon.</p>
projects / thirdparty / ntp.git / commitdiff
