r8 - 2007-05-05 - 16:44:25 - SteveKosteckeYou are here: NTP >  Support Web > ConfiguringNTP > ConfiguringRefclocks > ConfiguringIrigRefclocks
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
REFACTOR See ConfiguringIrigRefclocksDev for discussion of this topic.

6.1.7. Configuring Irig Refclocks

GPS, IEEE 1344, and NTP - a field report

In a system I'm involved with, we had a field failure, when time in the computers fed by a NTP time server fell out of bed at the turn of the year.

Symptom: After about one month of operation after the turn of the year, all communications with external systems abruptly failed because the systems at both ends were discarding all incoming traffic because the received messages appeared to come from too far in the past or future. On reading the NTP logs in the various computers, one can sense the sysadmin's rising frustration, as in early January 2005 he repeatedly killed and restarted the NTP daemons in those computers, all to no avail - the year was still wrong, claiming to be last year. Nor did manually setting the time help, as it soon reverted to the prior year. Eventally, the sysadmin made the symptom go away by killing the NTP daemons and then manually setting the time in each computer. This situation continued until external communications failed, at which time the offset was about a minute (after some 27 days of operation). This offset will be some combination of original setting error and subsequent clock drift.

Solution: It turned out that while the GPS receiver was configured to emit the 1344 data, the NTP timeserver was instead configured to ignore 1344 data, so the timeserver simply relived the year it was last set to, having no better information. (The sysadmin didn't try setting time on the timeserver.) Enabling 1344 data at both IRIG sender (GPS receiver) and IRIG receiver (NTP timeserver) solved the problem. The long-term solution was to update the maintenance manuals.

Hardware configuration: A GPS receiver feeds a colocated NTP timeserver via a 2-meter coax cable carrying IRIG-B122 signals, with two digits of Gregorian Year carried in the IEEE Std 1344 data in the IRIG signal. The timeserver is a dedicated piece of hardware that distributes time to the rest of the system via ethernet by answering time request messages from the NTP daemons in the various computers.

Standards: IRIG 200-98 plus Appendix F of IEEE Std 1344-1995 (R2001) is what governs the system in question. (IRIG 200-04, which includes the Gregorian Year info and thus has no need of 1344, arrived after the system was designed and built.) Vanilla IRIG-B carries only the number of the day (0-365) within the current year, but doesn't tell you which year it is. IEEE 1344 compliant IRIG-B contains in addition the least significant two digits of the Gregorian year.

Related Topics: IrigRefclockUsers, bug_small.png Bug #406, bug_small.png Bug #407

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback