Harlan Stenn wrote: >Hi Philip, > > > >>>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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 > > > > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
