[Git][NTPsec/ntpsec][master] 10 commits: Minor fixes in docs, related to the time1 "g" suffix
Eric S. Raymond
gitlab at mg.gitlab.com
Sun Aug 18 22:20:59 UTC 2019
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
647ea088 by Sanjeev Gupta at 2019-08-18T13:46:06Z
Minor fixes in docs, related to the time1 "g" suffix
- - - - -
0e978b2e by Sanjeev Gupta at 2019-08-18T14:20:13Z
Proofread rollover.adoc
The text claimed the SHM driver was immune (along with the NMEA driver)
to rollover. This is incorrect, but is now fixable with the "g"
suffix to time1.
- - - - -
534b448f by Sanjeev Gupta at 2019-08-18T14:21:43Z
Correct the entry of the April 2019 rollover
This was incorrectly given as May 2019
- - - - -
f18607ca by Sanjeev Gupta at 2019-08-18T14:25:34Z
Clarify GPS rollover time scale
Rollover is in GPS Time, not UTC.
https://www.usno.navy.mil/USNO/time/gps/gps-week-number-rollover
- - - - -
c3347f8e by Sanjeev Gupta at 2019-08-18T14:28:02Z
Promote footnote to running text
On the web, the footnote is easy to miss
- - - - -
1a1b35f2 by Sanjeev Gupta at 2019-08-18T14:41:56Z
Add rollover.html link to the debug documentation
- - - - -
92b138e0 by Sanjeev Gupta at 2019-08-18T14:47:42Z
Document that tcp/123 is required for NTS
- - - - -
ebd1c37d by Sanjeev Gupta at 2019-08-18T14:54:36Z
Another place to document that 123/tcp may be required
- - - - -
1a42c283 by Sanjeev Gupta at 2019-08-18T15:03:41Z
Update authentic.html with NTS progress
- - - - -
c8e9a720 by Sanjeev Gupta at 2019-08-18T15:09:35Z
bitrate, not baudrate
Yes, this is being pedantic, but ...
- - - - -
7 changed files:
- docs/authentic.adoc
- docs/debug.adoc
- docs/driver_nmea.adoc
- docs/driver_oncore.adoc
- docs/includes/clock-options.adoc
- docs/ntpsec.adoc
- docs/rollover.adoc
Changes:
=====================================
docs/authentic.adoc
=====================================
@@ -209,14 +209,13 @@ infrastructure to secure and authenticate associations.
This section is a placeholder for complete documentation on NTS. The
NTS implementation is work in progress conforming to a draft RFC not
-yet accepted.
+yet (Aug 2019) accepted. A Quick Start Guide on the current implementation
+of NTS is available at
+link:NTS-QuickStart.html[Quick way to get NTS working] .
NTPsec's future direction is to fully support NTS and eventually
remove older, insecure authentication methods.
-There is some documentation of client-side configuration on the
-link:confopt.html#options[Server Commands and Options] page.
-
[[windows]]
== Microsoft Windows Authentication
=====================================
docs/debug.adoc
=====================================
@@ -38,9 +38,10 @@ with configuration and network troubles.
Some problems are immediately apparent when the daemon first starts
running. The most common of these are the lack of a UDP port for NTP
(123) in the Unix +/etc/services+ file (or equivalent in some systems).
-*Note that NTP does not use TCP in any form. Also note that NTP requires
-port 123 for both source and destination ports.* These facts should be
-pointed out to firewall administrators.
+*Note that NTP requires port 123 for both source and destination ports.*
+These facts should be pointed out to firewall administrators.
+If you are using link:NTS-QuickStart.html[NTS], you also need to
+add an entry for TCP port 123.
Other problems are apparent in the system log, which ordinarily shows
the startup banner, some cryptic initialization data and the computed
@@ -59,6 +60,10 @@ utility can be used to verify a partial or complete path exists. Most
problems reported to the NTP newsgroup are not NTP problems, but
problems with the network or firewall configuration.
+If you use GPS, and your time is off by 19 years, you may have been
+bitten by the GPS rollover bug.
+Please see link:rollover.html[Rollover issues in time sources]
+
== Verifying Correct Operation
Unless using the +iburst+ option, the client normally takes a few
@@ -222,9 +227,8 @@ If the +ntpq+ or program does not show that messages are being
received by the daemon or that received messages do not result in
correct synchronization, verify the following:
-1. Verify the +/etc/services+ file host machine is configured to accept
-UDP packets on the NTP port 123. NTP is specifically designed to use UDP
-and does not respond to TCP.
+1. Verify the +/etc/services+ file host machine has an entry for 123/udp.
+If you are using NTS, you must also have an entry for 123/tcp.
2. Check the system log for +ntpd+ messages about configuration errors,
name-lookup failures or initialization problems. Common system log
=====================================
docs/driver_nmea.adoc
=====================================
@@ -52,7 +52,7 @@ The various GPS sentences that this driver recognises look like this
Important caveats: If your NMEA device does not ship GPZDA, you cannot
use it to run autonomously without a check peer, or expect recovery
from a trashed system clock. Also, dates from old NMEA devices are
-vulnerable to era wraparound; the NMEA dtiver has an internal trick
+vulnerable to era wraparound; the NMEA driver has an internal trick
that attempts to detect this, but one or more "g" suffixes on your
'time1' option may be useful as a workaround.
=====================================
docs/driver_oncore.adoc
=====================================
@@ -30,11 +30,11 @@ on your 'time1' option may be useful as a workaround.
This driver supports most models of the
https://web.archive.org/web/19990427102123/http://www.mot.com/AECS/PNSB/products/produt.html[Motorola Oncore GPS receivers]
(Basic, PVT6, VP, UT, UT+, GT, GT+, SL, M12, M12+T), as long as they
-support the _Motorola Binary Protocol_. All are long end-of-lifed as of 2019.
+support the _Motorola Binary Protocol_. All are long end-of-lifed as of 2019.
The (formerly) interesting versions of the Oncore were the VP, the
UT+, the "Remote" which is a prepackaged UT+, and the M12 Timing
-variant.
+variant.
However, there is one current hardware product that is reported good
with this driver; the
@@ -42,7 +42,7 @@ https://www.cnssys.com/cnsclock/CNSClockII.php[CNS Clock II]. It
ships 1PPS on the DCD line of its RS232 port or as a DCD priority
packet on USB. Older revisions of the product used M12 hardware,
newer ones use a u-blox engine but emulate OnCore behavior. Future
-versions will drop OnCore reporting enturely, at which time the
+versions will drop OnCore reporting entirely, at which time the
possibility of removing this driver will be revisited.
See the CNS Clock vendor product page for specfications.
=====================================
docs/includes/clock-options.adoc
=====================================
@@ -37,11 +37,11 @@
Specifies a constant to be added to the time offset produced by the
driver, a fixed-point decimal number in seconds. Each "g" on the
end of the constant adds the number of seconds in a 10-bit GPS
- era; each "G" adds the number of seconds in a 13-bit GPS era. This is used as a
- calibration constant to adjust the nominal time offset of a
- particular clock to agree with an external standard, such as a
+ era; each "G" adds the number of seconds in a 13-bit GPS era. This
+ is used as a calibration constant to adjust the nominal time offset
+ of a particular clock to agree with an external standard, such as a
precision PPS signal. It also provides a way to correct a systematic
- error or bias due to era wraparound from a GPS device,
+ error or bias due to era wraparound from a GPS device,
serial port or operating system latencies,
different cable lengths or receiver internal delay. The specified
offset is in addition to the propagation delay provided by other
=====================================
docs/ntpsec.adoc
=====================================
@@ -293,7 +293,7 @@ to the security-critical core.
maxdisp". See RFC 5905 for discussion of this synchronization
parameter.
-* The default baudrate of the NMEA driver has been changed to 9600 to
+* The default bitrate of the NMEA driver has been changed to 9600 to
match the default speed of almost all modern GPSes. The code can be
built in a strict NTP Classic compatibility mode that restores the
old 4800bps default.
=====================================
docs/rollover.adoc
=====================================
@@ -96,9 +96,9 @@ has been trashed or zeroed due to a failed battery backup and
you have no remote check peers yet.
Warnings have been attached to the documentation of NTP clock drivers
-that may have a vulnerability here. Notably, the NMEA and SHM drivers
-(probably the two in most common use) do *not* have this problem; the
-NMEA driver uses a clever calendrical trick to deduce a 4-digit year
+that may have a vulnerability here. Notably, the NMEA driver
+does *not* have this problem; it
+uses a clever calendrical trick to deduce a 4-digit year
that should work until 2399.
=== Unix time
@@ -118,8 +118,8 @@ would skip that second.
The possibility of stutter or skip also means that in order to compute
elapsed time in seconds between two Unix times, you need to know
the leap second offset at each time. It is not guaranteed that
-these offsets are the same if the interval crosses midnight at the
-end of any calendar month. To date in 2018, IERS (the International
+these offsets are the same if the interval crosses midnight at the
+end of any calendar month. To date in 2018, IERS (the International
Earth Rotation service) has performed all corrections just after
midnight of June 31 and December 31 respectively.
@@ -129,7 +129,7 @@ synchronized to the solar calendar. With it, Unix time after
Time) coincides with UTC. Unix time before 1972 was an approximation
of GMT (Greenwich Mean Time) without leap seconds.
-On POSIX-compliant Unix systems (which is now effectively all) Unix
+On POSIX-compliant Unix systems (which are now effectively all) Unix
time can be retrieved with nanosecond precision; some older versions
supported only millisecond precision. The subseconds counter is not
involved in any of the rollover or leap second issues with the
@@ -168,11 +168,14 @@ Raw GPS time is expressed as weeks since the GPS epoch
1980-01-06T00:00:00, and seconds within the week. Due to cost
constraints at the time the system was designed, the week counters are
only 10 bits long; thus, GPS time has a period of 1024 weeks (a bit
-over 19 years) footnote:[It is planned that future GPS satellites will
-increase the week counter length to 13 bits, for a period of 8192
-weeks or more than 157 years]. At time of writing, two GPS rollovers
+over 19 years). At time of writing, two GPS rollovers
have occurred; the first at 1999-08-22T00:00:00 and the second at
-2019-05-06T00:00:00.
+2019-04-06T00:00:00. Note that these times are "GPS Time", not
+UTC.
+
+It is planned that future GPS satellites will increase the week
+counter length to 13 bits, for a period of 8192 weeks or more
+than 157 years.
(GPS was originally designed for military geolocation, not time
service. It does not seem to have occurred to the originators that
@@ -201,7 +204,10 @@ firmware - especially in inexpensive consumer-grade devices - is
often low-quality and poorly tested due to vendors trying to squeeze
every possible dime out of their costs. Even major vendors like
SiRF have a history of embarrassing firmware glitches, and the
-semi-anonymous outfits in Shenzhen and on Taiwan are worse.
+semi-anonymous outfits in Shenzhen and Taiwan are worse.
+
+Cheaper,consumer-grade, GPS devices also suffer from early EOL, and
+manufacturers may never release firmware updates.
The worst impact of careless, low-budget design when using a GPS as
an NTP clock is not around either jitter or leap second corrections,
@@ -268,7 +274,8 @@ NTPsec includes a workaround option for these old devices. Each "g"
suffix on the 'time1' offset option for a device adds the number of seconds
in a 1024-week era; this corresponds to the 10-bit week counters used
in today's GNSS. "G" adds the number of seconds in the 8192-week era
-of te future.
+of te future. Unfortunately, this will only be useful *after* you
+detect a rollover.
A fairly bulletproof mitigation strategy, if you are running
autonomously, is to have multiple GPS clocks per server and replace
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/a62b6d981d179a4b20963c40023624df6aac40ae...c8e9a720a5911b1c8bb9bd079093fbff54a7c5d4
--
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/a62b6d981d179a4b20963c40023624df6aac40ae...c8e9a720a5911b1c8bb9bd079093fbff54a7c5d4
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20190818/0ea9d4eb/attachment-0001.htm>
More information about the vc
mailing list