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.

6.1.8. Configuring Jupiter Refclock with linux

This driver is only valid for Jupiter GPS Modules that support the Rockwell/Conexant/Navman binary interface (up to the model 12 modules). The newer models seem to have switched to the SiRF / NMEA protocols.

I have a working setup with linux-2.4.21-NANO and a Jupiter GPS receiver.

Here is the orginal Refclock Jupiter documentation.

These notes are for these versions. They assume you have already patched the kernel with PPSkit, compiled and installed a working NANO-kernel.

• linux-2.4.21.tar.gz
• PPSkit-2.1.4.tar.gz
• ntp-stable-2.4.0a-20040617.tar.gz

To enable kernel PPS disipline you need edit one line in refclock_jupiter.c. See diff below

@@ -232,5 +232,5 @@
 #ifdef HAVE_PPSAPI
        instance->assert = 1;
-       instance->hardpps = 0;
+       instance->hardpps = 1;   // Enable kernel PPS dicipline
        /*
         * Start the PPSAPI interface if it is there. Default to use

Note that there seems to be a patch floating around that fixes the hardpps issue.

NTP builds refclock_jupiter by default, if the necessary bits are found.

Jupiter specific lines from my ntp.conf

      # Jupiter binary mode
      server 127.127.31.0 prefer        #
      fudge 127.127.31.0 time1 0.00     #
      fudge 127.127.31.0 flag3 1        # I use the nonstandard edge on the PPS signal

With the 62euro kit from GPSKIT, I get quite good performance.

# ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.sth.netnod .PPS.            1 u   40  512  377   12.084    0.442   0.337
+ntp2.sth.netnod .PPS.            1 u   47  512  377   12.006    0.415   0.299
-ntp1.mmo.netnod .PPS.            1 u   67  512  377   20.919   -0.222   0.264
-ntp2.mmo.netnod .PPS.            1 u   44  512  377   20.808   -0.263   0.217
+ntp1.sp.se      .PPS.            1 u   32  512  377   17.369    0.084   0.199
+ntp2.sp.se      .PPS.            1 u   43  512  377   17.131    0.002   0.263
*GPS_JUPITER(0)  .GPS.            0 l   14   64  377    0.000    0.000   0.001

# ntptime
ntp_gettime() returns code 0 (OK)
  time c4a80538.8eb6f164  Tue, Jul 20 2004 22:55:20.557, (.557479878),
  maximum error 2934 us, estimated error 0 us, TAI offset -1073743080
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -0.023 us, frequency 37.670 ppm, interval 32 s,
  maximum error 2934 us, estimated error 0 us,
  status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
  time constant 7, precision 1.788 us, tolerance 496 ppm,
  pps frequency 37.670 ppm, stability 0.144 ppm, jitter 0.405 us,
  intervals 1751, jitter exceeded 3449, stability exceeded 44, errors 21.

It is also possible to have a Jupiter GPS receiver output NMEA messages. However, this is not recommended, since the receiver outputs NMEA when everything else is done. They can be either 1+ seconds late or 2+ seconds late (it can vary based on time / day). Since there is no way the NMEA message can reliably tell what second a PPS edge belongs to, this GPS receiver is unusable for precision timing in NMEA mode.

-- BjornGabrielsson - 20 Jul 2004

Related Topics: JupiterRefclockUsers