Generic NMEA GPS Receiver

From: Harlan Stenn Date: Wed, 19 Jan 2011 06:58:52 +0000 (-0500) Subject: Documentation updates from Dave Mills X-Git-Tag: NTP_4_2_7P120~7 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f4bfaee94fb587507e9c7fb239bc7142a7309097;p=thirdparty%2Fntp.git Documentation updates from Dave Mills bk: 4d368bacE-2-qxnCvYnzHRzdCX-cwQ --- diff --git a/ChangeLog b/ChangeLog index a93b2e479..f9d60de7b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +* Documentation updates from Dave Mills. (4.2.7p119) 2011/01/18 Released by Harlan Stenn * added timespecops.{c,h} and tievalops.{c.h} to libntp and include added tspecops.cpp to tests/libntp diff --git a/html/authopt.html b/html/authopt.html index c4e4d4992..bf5ebb917 100644 --- a/html/authopt.html +++ b/html/authopt.html @@ -20,7 +20,7 @@ color: #FF0000; gif

from Alice's Adventures in Wonderland, Lewis Carroll

Our resident cryptographer; now you see him, now you don't.

Last update: - 31-Dec-2010 6:20 + 02-Jan-2011 4:45 UTC

Autokey Public-Key Authentication

Last update: - 01-Jan-2011 2:41 + 15-Jan-2011 21:26 UTC

@@ -35,13 +35,13 @@

Optional identity schemes described on the Autokey Identity Schemes page are based on cryptographic challenge/response exchanges. Optional identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficult 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 Autonomous Authentication page.

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.

Autokey 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, while 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.

Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the ntp-keygen 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.

There are two timeouts associated with the Autokey scheme. The key list timeout is set by the automax 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 revoke timeout is set by the revoke 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.

Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the ntp-keygen 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 client and the time period over which the the 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.

There are two timeouts associated with the Autokey scheme. The key list timeout is set by the automax command, which specifies the interval between generating new key lists by the client or server. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The revoke timeout is set by the revoke 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.

Autokey Subnets

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. Note that the requirement that the NTP subnet be acyclic means that, if hosts are configured with each other in symmetric modes, each must be a TH. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or one or more trusted agents (TAs) of a parent subnet. NTP subnets can be nested, with the THs of a child subnet configured for one or more TAs of the parent subnet. The TAs can serve one or more child subnets, each with its own security policy and set of THs.

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. Note that the requirement that the NTP subnet be acyclic means that, if two hosts are configured with each other in symmetric modes, each must be a TH. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or one or more trusted agents (TAs) of a parent subnet. NTP subnets can be nested, with the THs of a child subnet configured for one or more TAs of a parent subnet. The TAs can serve one or more child subnets, each with its own security policy and set of THs.

A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. The requirement that the subnet be acyclic means certificate trails can never loop. NTP servers operate as certificate authorities (CAs) to sign certificates provided by their clients. The CAs include the TAs of the parent subnet and those subnet servers with dependent clients.

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.

The Autokey protocol runs for each association separately; but, 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 protocol. During the protocol, the client recursively obtains 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.

The Autokey protocol runs for each association separately, During the protocol, the client recursively obtains 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.

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.

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. 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 protocol.

Example

@@ -50,6 +50,10 @@

Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Alice and Helen are parent groups for Carol with TA C belonging to Alice and TA S belonging to Helen. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server, child subnet TH X has two mobilized associations, one to Alice TA host C and the other to Carol TA host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.

Note that host D certificate trail is D→C→A or D→C→B, depending on the particular order the trails are built. Host Y certificate trail is only Y→X, since X is a TH. Host X has two certificate trails X→C→A or X→C→B, and X→S→R.

Subnet Group Names

In some configurations where more than one subnet shares an Ethernet or when multiple subnets exist in a manycast or pool configuration, it is useful to isolate one subnet from another. In Autokey this can be done using subnet group names. An Autokey host name is specified by the -s option of the ntp-keygen program using the syntax host@group, where host is the host name and group is the optional subnet group name. If host is omitted, the host name defaults to the string returned by the Unix gethostname() routine. Thus, for host beauregard.udel.edu the option -s @red specifies the Autokey host name beauegard.udel.edu@red.

A subnet host with a given group name will discard ASSOC packets from all subnets with a different group name. This effectively disables the Autokey protocol without additional packet overhead. For instance, one or more manycast or pool servers will not respond to ASSOC packets from subnets with difference group names. Groups sharing an Ethernet will be filtered in the same way.

However, as shown in Figure 1, there are configurations where a TH of one group needs to listen to a TA of a different group. This is accomplished using the ident option of the crypto command and/or the ident option of the server command. The former case applies to all hosts sharing a common broadcast, manycast or symmetric passive modes, while the latter case applies to each individual client/server or symmetric active mode association. In either case the host listens to the specified group name in addition to the group name specified in the -s option of the ntp-keygen program.

NTP Secure Groups

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 Autokey Identity Schemes page. NTP secure groups are used to define cryptographic compartments and security hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.

@@ -73,7 +77,7 @@ key message digest algorithm. If compliance with FIPS 140-2 is required, the algorithm must be ether SHA or SHA1. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.

Example

Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S are run an identity exchange with child group TH X. Both have the same encrlypted keys file and X the common plarameters file.

Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S run an identity exchange with child group TH X. Both have the same encrypted keys file and X the common parameters file.

Configuration - Authentication Schemes

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. time.nist.gov, as root:

# cd /usr/local/etc @@ -95,17 +99,17 @@ the algorithm must be ether SHA or SHA1. The Autokey message d

It is possible to configure clients of server grundoon.udel.edu in the same way with the server line pointing to grundoon.udel.edu. Dependent clients authenticate to time.nistg.gov through grundoon.udel.edu.

In the above configuration examples, the default Autokey host name is the string returned by the Unix gethostname() 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 -s option of the ntp-keygen program. The default password can be changed using the -p option of the ntp-keygen program and the pw option of the crypto command. Configuration - Identity Schemes - The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. A parent subnet TA generates IFF tidentity files using an ntp-keygen program command with options specified in this section, while the child secure group TH uses the same program command with no options. Both the TA and TH use the crypto command with no options. In addition, the TH specifies options for the server and ident commands as described in this section. + The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. A parent subnet TA generates IFF identity files using an ntp-keygen program command with options specified in this section, while the child secure group TH uses the same program command with no options. Both the TA and TH use the crypto command with no options. In addition, the TH specifies options for the server and ident commands as described in this section. It's best to start with a functioning TC configuration and add commands as necessary. For example, the TA generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the command ntp-keygen -I. Note the TA is not necessarily a trusted host, so may not need the -T option. The nonencrypted client parameters can be exported using the command ntp-keygen -e >file, where the -e option redirects the client parameters to file via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command ntp-keygen -q passw2 >file, -where passwd2 is the read password for another TH. While the file name used for the client parameters file is arbitrary, it is common practice to use a mnemonic group name like red. On the other hand, the file name used for the keys file must follow the conventions desdribed on the ntp-keygen page. The encrypted server keys file is exported to other TAs that may serve the secure group, while the nonencrypted client parameters file can be distributed to all THs by nonsecure means. -To complete the configuration, the TH includes the client parameters file name as the ident option of the the server command for the TA assocition +where passwd2 is the read password for another TH. While the file name used for the client parameters file is arbitrary, it is common practice to use the subnet group name as described above, such as red. On the other hand, the file name used for the keys file must follow the conventions described on the ntp-keygen page. The encrypted server keys file is exported to other TAs that may serve the secure group, while the nonencrypted client parameters file can be distributed to all THs by nonsecure means. +To complete the configuration, the TH includes the client parameters file name as the ident option of the the server command for the TA association server 1.2.3.4 ident group, - where group is the chosen group name, in this case red. In addtion, if operating as a broadcast/multicast client or a symmmetric passive peer, the TH includes an ident command + where group is the chosen group name, in this case red. In addition, if operating as a broadcast/multicast client or a symmetric passive peer, the TH includes an ident command ident group, where group is the chosen group name, in this case red. Identity Schemes and Cryptotypes diff --git a/html/copyright.html b/html/copyright.html index 25fb10a25..f01635b4d 100644 --- a/html/copyright.html +++ b/html/copyright.html @@ -8,14 +8,14 @@ Copyright Notice "Clone me," says Dolly sheepishly. -Last update: 01-Jan-2011 11:29 UTC + Last update: 03-Sep-2010 21:20 UTC 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. *********************************************************************** * * -* Copyright (c) David L. Mills 1992-2011 * +* Copyright (c) David L. Mills 1992-2010 * * * * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose with or without fee is hereby * diff --git a/html/drivers/driver20.html b/html/drivers/driver20.html index 9b871a937..388148cc8 100644 --- a/html/drivers/driver20.html +++ b/html/drivers/driver20.html @@ -1,105 +1,343 @@ + + Generic NMEA GPS Receiver + + + + - - - - - Generic NMEA GPS Receiver - - - - - Generic NMEA GPS Receiver - - Synopsis - Address: 127.127.20.u - Reference ID: GPS - Driver ID: GPS_NMEA - Serial Port: /dev/gpsu; 4800 - 115200 bps, 8-bits, no parity - Serial Port: /dev/gpsppsu; for just the PPS signal (this is tried first for PPS, before /dev/gpsu) - Serial Port: /dev/gpsu; symlink to server:port (for nmead) Features: tty_clk - Description - This driver supports GPS receivers with the $GPRMC, $GPGLL, $GPGGA, $GPZDA, and $GPZDG NMEA sentences by default. Note that Accord's custom NMEA sentence $GPZDG reports using the GPS timescale, while the rest of the sentences report UTC. The difference between the two is a whole number of seconds which increases with each leap second insertion in UTC. To avoid problems mixing UTC and GPS timescales, the driver disables processing of UTC sentences once $GPZDG is received. - The driver expects the receiver to be set up to transmit at least one supported sentence every second. - The accuracy depends on the receiver used. Inexpensive GPS models are available with a claimed PPS signal accuracy of 1 ms or better relative to the broadcast signal. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system. - If the Operating System supports PPSAPI (RFC 2783), fudge flag1 1 enables its use. - The various GPS sentences that this driver recognises look like this: - (others quietly ignored) - $GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf> -$GPGLL,LAT,LAT_REF,LONG,LONG_REF,UTC,POS_STAT*CS<cr><lf> -$GPGGA,UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS<cr><lf> -$GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS<cr><lf> -$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS<cr><lf> - - UTC - Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff]) - POS_STAT - Position status. (A = Data valid, V = Data invalid) - LAT - Latitude (llll.ll) - LAT_REF - Latitude direction. (N = North, S = South) - LON - Longitude (yyyyy.yy) - LON_REF - Longitude direction (E = East, W = West) - SPD - Speed over ground. (knots) (x.x) - HDG - Heading/track made good (degrees True) (x.x) - DATE - Date (ddmmyy) - MAG_VAR - Magnetic variation (degrees) (x.x) - MAG_REF - Magnetic variation (E = East, W = West) - FIX_MODE - Position Fix Mode (0 = Invalid, >0 = Valid) - SAT_USED - Number Satellites used in solution - HDOP - Horizontal Dilution of Precision - ALT - Antenna Altitude - ALT_UNIT - Altitude Units (Metres/Feet) - GEO - Geoid/Elipsoid separation - G_UNIT - Geoid units (M/F) - D_AGE - Age of last DGPS Fix - D_REF - Reference ID of DGPS station - GPSTIME - Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.f]) - DD - Day of the month (1-31) - MM - Month of the year (1-12) - YYYY - Year - AA.BB - Denotes the signal strength (should be < 05.00) - V - GPS sync status - '0' => INVALID time, - '1' => accuracy of +/- 20ms, - '2' => accuracy of +/- 100ns - CS - Checksum - <cr><lf> - Sentence terminator. - -Specific GPS sentences and bitrates may be selected by setting bits of the 'mode' in the server configuration line: - server 127.127.20.x mode X bit 0 - process $GPMRC (value = 1) bit 1 - process $GPGGA (value = 2) bit 2 - process $GPGLL (value = 4) bit 4 - process $GPZDA or $GPZDG (value = 8) - The default (mode 0) is to process all supported sentences, which results in the last received each cycle being used. Multiple sentences may be selected by adding their mode bit values. The driver uses 4800 bits per second by default. Faster bitrates can be selected using bits 4, 5, and 6 of the mode field: - bits 4/5/6 - select serial bitrate (0 for 4800 - the default, 16 for 9600, 32 for 19200, 48 for 38400, 64 for 57600, 80 for 115200) - The driver will send a $PMOTG,RMC,0000*1D<cr><lf> command each poll interval. This is not needed on most GPS receivers because they automatically send $GPRMC every second, but helps a Motorola GPS receiver that is otherwise silent. NMEA devices ignore commands they do not understand. - Setting up the Garmin GPS-25XL - Switch off all output with by sending it the following string. - "$PGRMO,,2<cr><lf>" - Now switch only $GPRMC on by sending it the following string. - "$PGRMO,GPRMC,1<cr><lf>" - On some systems the PPS signal isn't switched on by default. It can be switched on by sending the following string. - "$PGRMC,,,,,,,,,,,,2<cr><lf>" - Monitor Data - The GPS sentence that is used is written to the clockstats file and available with ntpq -c clockvar. - Fudge Factors - - time1 time - Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0. - time2 time - Specifies the serial end of line time offset calibration factor, in seconds and fraction, with default 0.0. - stratum number - Specifies the driver stratum, in decimal from 0 to 15, with default 0. - refid string - Specifies the driver reference identifier, an ASCII string from one to four characters, with default GPS. - flag1 0 | 1 - Disable PPS signal processing if 0 (default); enable PPS signal processing if 1. - flag2 0 | 1 - If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1. - flag3 0 | 1 - If PPS signal processing is enabled, use the ntpd clock discipline if 0 (default); use the kernel discipline if 1. - flag4 0 | 1 - Obscures location in timecode: 0 for disable (default), 1 for enable. - - Additional Information - Reference Clock Drivers - - - - - + + + + Generic NMEA GPS Receiver + + Synopsis + + + Address: 127.127.20.u + Reference ID: GPS + Driver ID: GPS_NMEA + Serial Port: /dev/gpsu; 4800 - 115200 bps, 8-bits, no parity + Serial Port: /dev/gpsppsu; for just the PPS signal (this + is tried first for PPS, before /dev/gpsu) + Serial Port: /dev/gpsu; symlink to server:port (for nmead) + Features: tty_clk + + + Description + + + This driver supports GPS receivers with + the $GPRMC, $GPGLL, $GPGGA, $GPZDA + and $GPZDG NMEA sentences by default. Note that Accord's + custom NMEA sentence $GPZDG reports using the GPS timescale, + while the rest of the sentences report UTC. The difference between + the two is a whole number of seconds which increases with each leap + second insertion in UTC. To avoid problems mixing UTC and GPS + timescales, the driver disables processing of UTC sentences + once $GPZDG is received. + + + The driver expects the receiver to be set up to transmit at least one + supported sentence every second. + + + The accuracy depends on the receiver used. Inexpensive GPS models are + available with a claimed PPS signal accuracy of + 1 ms or better relative to the broadcast + signal. However, in most cases the actual accuracy is limited by the + precision of the timecode and the latencies of the serial interface and + operating system. + + + If the Operating System supports PPSAPI + (RFC 2783), fudge flag1 + 1 enables its use. + + + The various GPS sentences that this driver recognises look like this: + (others quietly ignored) + + + + + + + + + + + + + + + + + + + + Accepted NMEA sentencesSentence Vendor $GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf> $GPGLL,LAT,LAT_REF,LON,LON_REF,UTC,POS_STAT*CS<cr><lf> $GPGGA,UTC,LAT,LAT_REF,LON,LON_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS<cr><lf> $GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS<cr><lf> $GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS<cr><lf> Accord + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + NMEA data itemsSymbol Meaning and Format UTC Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff]) POS_STAT Position status. (A = Data valid, V = Data invalid) LAT Latitude (llll.ll) LAT_REF Latitude direction. (N = North, S = South) LON Longitude (yyyyy.yy) LON_REF Longitude direction (E = East, W = West) SPD Speed over ground. (knots) (x.x) HDG Heading/track made good (degrees True) (x.x) DATE Date (ddmmyy) MAG_VAR Magnetic variation (degrees) (x.x) MAG_REF Magnetic variation (E = East, W = West) FIX_MODE Position Fix Mode (0 = Invalid, >0 = Valid) SAT_USED Number of Satellites used in solution HDOP Horizontal Dilution of Precision ALT Antenna Altitude ALT_UNIT Altitude Units (Metres/Feet) GEO Geoid/Elipsoid separation G_UNIT Geoid units (M/F) D_AGE Age of last DGPS Fix D_REF Reference ID of DGPS station GPSTIME Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.f]) DD Day of the month (1-31) MM Month of the year (1-12) YYYY Year AA.BB Denotes the signal strength (should be < 05.00) V GPS sync status + '0' => INVALID time, + '1' => accuracy of +/- 20ms, + '2' => accuracy of +/- 100ns CS Checksum <cr><lf> Sentence terminator. + + + The 'mode' byte + + + Specific GPS sentences and bitrates may be selected by setting bits of + the 'mode' in the server configuration line: server + 127.127.20.x mode X + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + mode byte bits and bit groupsBit Dec. Meaning 0 1 process $GPMRC 1 2 process $GPGGA 2 4 process $GPGLL 3 8 process $GPZDA or $GPZDG 4-6 0 linespeed 4800bps 16 linespeed 9600bps 32 linespeed 19200bps 48 linespeed 38400bps 64 linespeed 57600bps 80 linespeed 115200bps 7 128 Write the sub-second fraction of the receive time stamp to the + clockstat file for all recognised NMEA sentences. This can be used to + get a useful value for fudge time2. Caveat: This + will fill your clockstat file rather fast. Use it only temporarily to + get the numbers for the NMEA sentence of your choice. + + + + The default (mode 0) is to process all supported sentences at a linespeed + of 4800bps, which results in the first one received and recognised in + each cycle being used. If only specific sentences should be + recognised, then the mode byte must be chosen to enable only the selected + ones. Multiple sentences may be selected by adding their mode bit + values, but of those enabled still only the first received sentence in a + cycle will be used. Using more than one sentence per cycle is + impossible, because + + there is only fudge time2 available to + compensate for transmission delays but every sentence would need a + different one and + using more than one sentence per cycle overstuffs the internal data + filters. + + The driver uses 4800 bits per second by default, but faster bitrates can + be selected using bits 4 to 6 of the mode field. + + + + Caveat: Using higher line speeds does not necessarily + increase the precision of the timing device. Higher line speeds are + not necessarily helpful for the NMEA driver, either. They can be + used to accomodate for an amount of data that does not fit into a + 1-second cycle at 4800bps, but high-speed high-volume NMEA data is likely + to cause trouble with the serial line driver since NMEA supports no + protocol handshake. Any device that is exclusively used for time + synchronisation purposes should be configured to transmit the relevant + data only, e.g. one $GPRMC or $GPZDA per second, at a + linespeed of 4800bps or eventually 9600bps. + + + + Configuring + NMEA Refclocks might give further useful hints for specific hardware + devices that exhibit strange or curious behaviour. + + + + To make a specific setting, select the corresponding decimal values from + the mode byte table, add them all together and enter the resulting + decimal value into the clock configuration line. + + + + The driver will send a $PMOTG,RMC,0000*1D<cr><lf> + command each poll interval. This is not needed on most GPS + receivers because they automatically send $GPRMC every second, + but helps a Motorola GPS receiver that is otherwise silent. NMEA + devices ignore commands they do not understand. + + + Setting up the Garmin GPS-25XL + + Switch off all output with by sending it the following string. + "$PGRMO,,2<cr><lf>" + Now switch only $GPRMC on by sending it the following string. + "$PGRMO,GPRMC,1<cr><lf>" + + On some systems the PPS signal isn't switched on by default. It can be + switched on by sending the following string. + "$PGRMC,,,,,,,,,,,,2<cr><lf>" + + Monitor Data + + The GPS sentence that is used is written to the clockstats file and + available with ntpq -c clockvar. + + Fudge Factors + + + time1 time + Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0. + time2 time + Specifies the serial end of line time offset calibration factor, in seconds and fraction, with default + 0.0. + stratum number + Specifies the driver stratum, in decimal from 0 to 15, with default 0. + refid string + Specifies the driver reference identifier, an ASCII string from one to four characters, with + default GPS. + flag1 0 | 1 + Disable PPS signal processing if 0 (default); enable PPS signal processing if 1. + flag2 0 | 1 + If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the + falling edge if 1. + flag3 0 | 1 + If PPS signal processing is enabled, use the ntpd clock discipline if 0 (default); use the kernel + discipline if 1. + flag4 0 | 1 + Obscures location in timecode: 0 for disable (default), 1 for enable. + + + Additional Information + Reference Clock Drivers + + + diff --git a/html/keygen.html b/html/keygen.html index 1b0e275b3..e485e6744 100644 --- a/html/keygen.html +++ b/html/keygen.html @@ -5,18 +5,13 @@ ntp-keygen - generate public and private keys - ntp-keygen - generate public and private keys from Alice's Adventures in Wonderland, Lewis Carroll Alice holds the key. Last update: - 22-Dec-2010 21:55 + 15-Jan-2011 19:23 Related Links @@ -68,7 +63,7 @@ -H Generate a new encrypted RSA public/private host key file. -i group - Set the optional group name to group. This is used in the identity file names. If used, it must match the group name specified in the ident option of the crypto configuration command. + Set the optional group name to group. This is used in the identity file names. If used, it must match the file name specified in the ident option of the crypto configuration command. -I Generate a new encrypted IFF key file for the Schnorr (IFF) identity scheme. This option is mutually exclusive with the -G and -V options. -l days @@ -88,8 +83,8 @@ Generate a new encrypted public/private sign key file of the specified type. By default, the sign key is the host key and has the same type. If compatibly with FIPS 140-2 is required, the sign key type must be DSA. - -s host - Set the certificate subject and issues names to host. By default, the subject and issuer fields are the string returned by the Unix gethostname() routine. + -s host[@group] + Specify the Autokey host name, where host is the host name and group is the optional group name. The Autokey host name is also the certificate subject and issuer names. If host is not specified, the default host name is the string returned by the Unix gethostname() routine. -T Generate a trusted certificate. By default, the program generates nontrusted certificates. -V nkeys diff --git a/html/miscopt.html b/html/miscopt.html index e40ce9038..4686b2a60 100644 --- a/html/miscopt.html +++ b/html/miscopt.html @@ -10,7 +10,7 @@ from Pogo, Walt Kelly We have three, now looking for more. Last update: - 09-Dec-2010 15:22 + 11-Jan-2011 5:29 UTC Related Links @@ -44,7 +44,7 @@ ntp Enables time and frequency discipline. In effect, this switch opens and closes the feedback loop, which is useful for testing. The default for this flag is enable. stats - Enables the statistics facility. See the Monitoring Options page for further information. The default for this flag is disable. + Enables the statistics facility. See the Monitoring Options page for further information. The default for this flag is enabled. includefile includefile diff --git a/html/select.html b/html/select.html index 196b47a3f..347d54bc4 100644 --- a/html/select.html +++ b/html/select.html @@ -9,7 +9,7 @@ Clock Select Algorithm Last update: - 30-Sep-2010 19:59 + 04-Jan-2011 22:18 UTC The clock select algorithm determines from a set of candidates, which are correct (truechimers) and which are not (falsetickers) according to a set of formal correctness assertions. The principles are based on the observation that the maximum error in determining the offset of a candidate cannot exceed one-half the roundtrip delay to the primary reference clock at the time of measurement. This must be increased by the maximum error that can accumulate since then. In NTP the total, called the synchronization distance, is one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here. @@ -23,7 +23,7 @@ Figure 2. Clock Select Algorithm - The algorithm operates as shown in Figure 2.. Let m be the number of candidates and f the number of falsetickers, initially zero. Move a pointer from the leftmost endpoint towards the rightmost endpoint in Figure 1 and count the number of candidates, stopping when that number reaches m - f; this is the left endpoint of the intersection interval. Then, do the same, but moving from the rightmost endpoint towards the leftmost endpoint; this is the right endpoint of the intersection interval. If the left endpoint is greater than the right endpoint; i.e., the interval appears backwards. increase f by 1. If f is less than n / 2, try again; otherwise, the algorithm fails and no truechimers could be found.. + The algorithm operates as shown in Figure 2. Let m be the number of candidates and f the number of falsetickers, initially zero. Move a pointer from the leftmost endpoint towards the rightmost endpoint in Figure 1 and count the number of candidates, stopping when that number reaches m - f; this is the left endpoint of the intersection interval. Then, do the same, but moving from the rightmost endpoint towards the leftmost endpoint; this is the right endpoint of the intersection interval. If the left endpoint is greater than the right endpoint; i.e., the interval appears backwards. increase f by 1. If f is less than n / 2, try again; otherwise, the algorithm fails and no truechimers could be found.. The clock select algorithm then scans the associations. If the right endpoint of the correctness interval for a candidate is greater than the left endpoint of the intersection interval, or if the left endpoint of the correctness interval is less than the right endpoint of the intersection interval, the candidate is a truechimer; otherwise, it is a falseticker. In practice, with fast LANs and modern computers, the correctness interval can be quite small, especially when the candidates are multiple reference clocks. In such cases the intersection interval may be empty, due to insignificant differences in the reference clock offsets. To avoid this, the synchronization distance must be at least the value of mindist, with default 1 ms. This value can be changed using the mindist option of the tos command.

Related Links

Autokey Public-Key Authentication

Table of Contents

Autokey Subnets

Subnet Group Names

NTP Secure Groups

Configuration - Authentication Schemes

Configuration - Identity Schemes

Identity Schemes and Cryptotypes

Copyright Notice