[ntp:questions] Re: Issues w/ 4.2.0a, multicast, and porting 4.2.2 to Fedora Core
stenn at ntp.isc.org
Sun Sep 3 20:26:01 UTC 2006
>>> In article <44FB0C3B.9000406 at redfish-solutions.com>, philipp_subx at redfish-solutions.com (Philip Prindeville) writes:
Philip> Hi. I haven't poked around the guts of NTP in about 12 years, so
Philip> I'm a little rusty... (since 2.3???)
Much has changed...
Philip> And I'd like to build myself an RPM binary of 4.2.2, but the sources
Philip> don't build cleanly on Fedora Core 5...
Are there any open bug reports on this? If not, we need to know what the
problems are. If so, please let me know what they are and I'll see about
getting them fixed soon. I do know that I have been looking at fixing
Philip> and Fedora distros seem to
Philip> like to have a certain number of patches applied, like not running
Philip> as root.
No patch should be necessary to have ntpd drop root. What other patches are
Philip> Anyway, I noticed the following. When I configure an FC5 machine
Philip> multicastclient # listen on default 184.108.40.206
Philip> restrict 220.127.116.11 mask 255.255.255.255 nomodify notrap
Philip> restrict 192.168.1.1 mask 255.255.255.255 nomodify notrap
Philip> And run ntpd with the arguments:
Philip> ntpd -A -m -u ntp:ntp -p /var/run/ntpd.pid -g
Philip> that I notice it doesn't sync up with the multicast source... Rather
Philip> it discovers the multicast server, and then starts to use it as a
Philip> unicast server:
Ah, you are clearly looking for the information that belongs in
I suspect you can be of great help in getting some useful content there.
I'm happy to help with that.
You have seen http://www.eecis.udel.edu/~mills/ntp/html/assoc.html and
I would *love* to have another pair of eyes going over the code and
documentation in this area.
Philip> ... Is there a reason that ntpd isn't just synchronizing with the
Philip> mulicast packets instead?
The short answer is "yes". Now, however, we have to get to the longer
We have made changes to the interface code since 4.2.2 - I recommend you get
the latest ntp-dev tarball and start with it. Please note that we are about
to start the countdown to the 4.2.4 release and I would very much like to
have a resolution to the issues you are seeing ASAP. If it doesn't happen
in time for 4.2.4, I am planning to have the next release of NTP appear 6-8
months after 4.2.2.
Philip> why not just change the prototype of doquery(), for instance?
Philip> (As a side note, why would NULL ever need to be cast to (char *)?
Philip> (void *)0 is an untyped pointer, and hence implicitly casts to
Philip> whatever pointer the receiving parameter from the prototype takes...
Philip> Unless this needs to work not just with ISO/ANSI compilers, but with
Philip> K&R as well... is anyone still using pre-C99 compilers?)
Bing! We are still using K&R as the "base" compiler level.
I believe we had agreed that we would "upgrade" to ANSI C around now, and
I'm going to make sure about this with Dave in my next email to him. There
is something to be said for doing this for 4.2.4, and something to be said
for doing this as of 4.3.0.
Philip> Is there plug-and-play support for using GPS over USB natively
Philip> without having to do serial port emulation?
I would like to see more information on that here:
or if needed/useful, on a similar page dedicated to USB refclocks.
Philip> Oh, and as another sidebar: would it be worth defining bit 8 in
Philip> "server 127.127.20.x mode X" to mean "don't bother sending $PMOTG"
Philip> because the GPS receiver will do it anyway (without being told to)?
Please open an enhancement request for the ntp's NMEA refclock component at
More information about the questions