EditWYSIWYGAttachPrintable
r4 - 2005-06-19 - 08:12:00 - HarlanStennYou 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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

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.
%NAVBAR{prefix="
" suffix="
" graphics="on"}% REFACTOR See ConfiguringIrigRefclocksDev for discussion of this topic.

6.1.7. Configuring Irig Refclocks

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 the Gregorian year.

One site reported a problem after the beginning of a new year, as NTP was listening to the IRIG-B signal but was not getting the year data.

The problem was traced to a misconfigured NTP time server that was ignoring the 1344 data (which contains the Gregorian year) in the IRIG-B signal from the GPS receiver.

[Exactly how was ntpd misconfigured to cause this problem? I don't see how that is possible...]

On reading the NTP logs, you could just feel the rising frustration in the system administrator as he killed and restarted the NTP daemon, to no avail - the year was still wrong. Eventually, he just shut NTP off and set the computer clock by hand. This worked well enough for a while, but after two or three months the computer clock had drifted enough to cause communications to be lost (because message timestamps were so far off that the receiver threw the messages away).

The solution was to update the maintenance manuals to ensure that the 1344 information was both sent (by the GPS receiver) and received (by the NTP time server).

[Again, exactly what needed to be done to ntpd? By my read of the refclock_irig.c code we are expecting the gregorian year in the decoded data stream.]

Also see:

%NAVBAR{prefix="

" suffix="
" graphics="on"}%
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 | r6 < r5 < r4 < r3 | 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-2019 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