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

Philip Prindeville philipp_subx at redfish-solutions.com
Wed Sep 6 04:30:37 UTC 2006


Harlan Stenn wrote:

>Hi Philip,
>
>  
>
>>>>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
>https://ntp.isc.org/bugs/show_bug.cgi?id=693 next.
>
>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
>there?
>  
>

Let me get some patches together and I'll post them when I get something
that builds and runs.


>Philip> Anyway, I noticed the following.  When I configure an FC5 machine
>Philip> with:
>
>Philip> ...
>Philip> multicastclient # listen on default 224.0.1.1
>Philip> restrict 224.0.1.1 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
>
> http://ntp.isc.org/bin/view/Support/ConfiguringMulticastServers
>
>and
>
> http://ntp.isc.org/bin/view/Support/ConfiguringMulticastClients
>
>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
>http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html, right?
>  
>

I'm reading the manyopt.html section, and it seems that the client is
never coming out of the "volley" mode.

Not clear if I need to turn off authentication or not.

In any case, IOS (Ciscos) only implements NTP v1-v3. So I don't know
why the client would be using v4 mechanisms to dialog with the v3 server.

>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
>answer.
>
>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.
>  
>

Ok, no pressure... ;-)

>Philip> ...
>
>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.
>  
>

Well, it would simplify getting the code to compile on Linux with gcc
-Wall...

Might find some 64-bit issues, too.


>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:
>
> http://ntp.isc.org/Support/ConfiguringGarminRefclocks
>
>or if needed/useful, on a similar page dedicated to USB refclocks.
>  
>

Hmm... it would be nice to use USB's plug-n-play capabilities to detect
and autoconfigure it.

>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
>http://ntp.isc.org/bugs .
>  
>

Done:

https://ntp.isc.org/bugs/show_bug.cgi?id=699

>H
>
>
>  
>




More information about the questions mailing list