[ntp:questions] Issues w/ 4.2.0a, multicast, and porting 4.2.2 to Fedora Core

Philip Prindeville philipp_subx at redfish-solutions.com
Sun Sep 3 17:09:15 UTC 2006


Hi.

I haven't poked around the guts of NTP in about 12 years, so I'm a little
rusty... (since 2.3???)

I'm running Linux FC3 and FC5 on a variety of PC machines, with NTP set
up as a multicast client.  I'm using the distro RPM 4.2.0.a.20040617.  I
have
various Cisco routers set up to chime multicast running 12.2(20) to
12.4(9)T.

And I'd like to build myself an RPM binary of 4.2.2, but the sources don't
build cleanly on Fedora Core 5... and Fedora distros seem to like to have
a certain number of patches applied, like not running as root.

Anyway, I noticed the following.  When I configure an FC5 machine with:

...
multicastclient                 # listen on default 224.0.1.1
restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
restrict 192.168.1.1 mask 255.255.255.255 nomodify notrap

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10


And run ntpd with the arguments:

 ntpd -A -m -u ntp:ntp -p /var/run/ntpd.pid -g

that I notice it doesn't sync up with the multicast source... Rather it
discovers
the multicast server, and then starts to use it as a unicast server:

# ntpq -n -c peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     LOCAL(0)        10 l   34   64  377    0.000    0.000   0.001
*192.168.1.1     198.123.30.132   2 u    4 1024  377    1.190    0.321   0.024


in our environment, this doesn't scale well.  We have thousands of desktops,
and we're running QoS, so we end up generating a lot of EF traffic.  Not good.

I've attached packet traces below.

Is there a reason that ntpd isn't just synchronizing with the mulicast packets
instead?

"netstat" shows it as listening:

udp        0      0 224.0.1.1:123               0.0.0.0:* 
udp        0      0 192.168.1.7:123             0.0.0.0:* 
udp        0      0 127.0.0.1:123               0.0.0.0:* 
udp        0      0 0.0.0.0:123                 0.0.0.0:* 


So...  does anyone have the patches from 4.2.0a ported to 4.2.2 for Fedora?
I've started to do it, but some of the patches are dubious:


--- ntp-stable-4.2.0a-20040617/ntpdc/ntpdc_ops.c.wall   2004-05-25 07:02:25.000000000 -0400
+++ ntp-stable-4.2.0a-20040617/ntpdc/ntpdc_ops.c        2004-12-13 09:23:06.000000000 -0500
@@ -293,7 +293,7 @@

 again:
        res = doquery(impl_ver, REQ_PEER_LIST, 0, 0, 0, (char *)NULL, &items,
-                     &itemsize, (char **)&plist, 0,
+                     &itemsize, (char **)((void *)&plist), 0,
                      sizeof(struct info_peer_list));

        if (res == INFO_ERR_IMPL && impl_ver == IMPL_XNTPD) {


why not just change the prototype of doquery(), for instance?

(As a side note, why would NULL ever need to be cast to (char *)?
(void *)0 is an untyped pointer, and hence implicitly casts to whatever
pointer the receiving parameter from the prototype takes...  Unless
this needs to work not just with ISO/ANSI compilers, but with K&R as
well...  is anyone still using pre-C99 compilers?)

And lastly, I have some Garmin and OEM (I think I got them from
Provantage) USB GPS receivers.  They should all be capable of doing
NMEA 0183.

There are various issues with doing the Serial port over USB with
Lini variants (udev tends to create the devices in non-portable
ways depending on the distro).

Is there plug-and-play support for using GPS over USB natively
without having to do serial port emulation?

For instance, reading:

http://www.cis.udel.edu/~mills/ntp/html/drivers/driver20.html

do the drivers handle putting the port in the correct stty
modes, then sending the appropriate initialization string(s)?

Oh, and as another sidebar:  would it be worth defining bit 8
in "server 127.127.20.x mode X" to mean "don't bother sending
$PMOTG" because the GPS receiver will do it anyway (without
being told to)?

Thanks,

-Philip

========
% tcpdump -p -n -i eth0 -s 1024 -vv udp port 123
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1024 bytes
11:04:40.944217 IP (tos 0xc0, ttl   1, id 0, offset 0, flags [none], proto: UDP (17), length: 76) 192.168.1.1.ntp > 224.0.1.1.ntp: [udp sum ok] NTPv3, length 48
        Broadcast, Leap indicator:  (0), Stratum 2, poll 6s, precision -16
        Root Delay: 0.076324, Root dispersion: 0.006134, Reference-ID: 198.123.30.132
          Reference Timestamp:  3366291849.030097676 (2006/09/03 11:04:09)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3366291880.944903139 (2006/09/03 11:04:40)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3366291880.944903139 (2006/09/03 11:04:40)
11:05:21.446768 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 76) 192.168.1.7.ntp > 192.168.1.1.ntp: [udp sum ok] NTPv3, length 48
        Client, Leap indicator:  (0), Stratum 3, poll 7s, precision -20
        Root Delay: 0.079116, Root dispersion: 0.018188, Reference-ID: 192.168.1.1
          Reference Timestamp:  3366291790.447573999 (2006/09/03 11:03:10)
          Originator Timestamp: 3366291880.944903139 (2006/09/03 11:04:40)
          Receive Timestamp:    3366291880.944091999 (2006/09/03 11:04:40)
          Transmit Timestamp:   3366291921.446712999 (2006/09/03 11:05:21)
            Originator - Receive Timestamp:  -0.000811139
            Originator - Transmit Timestamp: +40.501809835
11:05:21.447911 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 76) 192.168.1.1.ntp > 192.168.1.7.ntp: [udp sum ok] NTPv3, length 48
        Server, Leap indicator:  (0), Stratum 2, poll 7s, precision -16
        Root Delay: 0.076324, Root dispersion: 0.006134, Reference-ID: 198.123.30.132
          Reference Timestamp:  3366291849.030097676 (2006/09/03 11:04:09)
          Originator Timestamp: 3366291921.446712999 (2006/09/03 11:05:21)
          Receive Timestamp:    3366291921.448752257 (2006/09/03 11:05:21)
          Transmit Timestamp:   3366291921.448774251 (2006/09/03 11:05:21)
            Originator - Receive Timestamp:  +0.002039257
            Originator - Transmit Timestamp: +0.002061251
11:05:44.926456 IP (tos 0xc0, ttl   1, id 0, offset 0, flags [none], proto: UDP (17), length: 76) 192.168.1.1.ntp > 224.0.1.1.ntp: [udp sum ok] NTPv3, length 48
        Broadcast, Leap indicator:  (0), Stratum 2, poll 6s, precision -16
        Root Delay: 0.076324, Root dispersion: 0.006134, Reference-ID: 198.123.30.132
          Reference Timestamp:  3366291849.030097676 (2006/09/03 11:04:09)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3366291944.927170669 (2006/09/03 11:05:44)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3366291944.927170669 (2006/09/03 11:05:44)
...






More information about the questions mailing list