Issues w/ 4.2.0a, multicast,and porting 4.2.2 to Fedora Core

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:

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

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



_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

Hi Philip,
[color=blue][color=green][color=darkred]
>>> In article <44FB0C3B.9000406@redfish-solutions.com>, [email]philipp_subx@redfish-solutions.com[/email] (Philip Prindeville) writes:[/color][/color][/color]

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
[url]https://ntp.isc.org/bugs/show_bug.cgi?id=693[/url] 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?

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

[url]http://ntp.isc.org/bin/view/Support/ConfiguringMulticastServers[/url]

and

[url]http://ntp.isc.org/bin/view/Support/ConfiguringMulticastClients[/url]

I suspect you can be of great help in getting some useful content there.
I'm happy to help with that.

You have seen [url]http://www.eecis.udel.edu/~mills/ntp/html/assoc.html[/url] and
[url]http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html[/url], right?

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.

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.

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:

[url]http://ntp.isc.org/Support/ConfiguringGarminRefclocks[/url]

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

H

Harlan Stenn wrote:[color=blue]
> 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.
>[/color]

Multicast works fine in 4.2.2. The changes to the interface code should
not affect this. If it did, it would be a bug.

Danny
_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

Philip Prindeville wrote:[color=blue]
> 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.[/color]

No you haven't, see below.
[color=blue]
> 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.
>[/color]

You need to use 4.2.2 as there were a large number of fixes to get
multicast working properly.
[color=blue]
> 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.
>[/color]

I cannot imagine why it would not build. What are the errors you get
during the build?
[color=blue]
> Anyway, I noticed the following. When I configure an FC5 machine with:
>
> ...
> multicastclient # listen on default 224.0.1.1[/color]

This is invalid. multicastclient requires an address, in this case
224.0.1.1. You should be seeing an error message in syslog.
[color=blue]
> 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[/color]

You don't need these lines unless you are providing ntp service to other
systems.
[color=blue]
>
>
> And run ntpd with the arguments:
>
> ntpd -A -m -u ntp:ntp -p /var/run/ntpd.pid -g
>[/color]

As near as I can figure out -m is not a valid option.
[color=blue]
> 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.
>[/color]

See above.
[color=blue]
> I've attached packet traces below.
>
> Is there a reason that ntpd isn't just synchronizing with the mulicast packets
> instead?
>[/color]

See above. I see nothing to indicate that it's listening for multicast
packets. If you build and run debug does it show the multicast interface
being set up?

Danny
_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

Harlan Stenn wrote:
[color=blue]
>Hi Philip,
>
>
>[color=green][color=darkred]
>>>>In article <44FB0C3B.9000406@redfish-solutions.com>, [email]philipp_subx@redfish-solutions.com[/email] (Philip Prindeville) writes:
>>>>
>>>>[/color][/color]
>
>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
>[url]https://ntp.isc.org/bugs/show_bug.cgi?id=693[/url] 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?
>
>[/color]

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

[color=blue]
>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
>
> [url]http://ntp.isc.org/bin/view/Support/ConfiguringMulticastServers[/url]
>
>and
>
> [url]http://ntp.isc.org/bin/view/Support/ConfiguringMulticastClients[/url]
>
>I suspect you can be of great help in getting some useful content there.
>I'm happy to help with that.
>
>You have seen [url]http://www.eecis.udel.edu/~mills/ntp/html/assoc.html[/url] and
>[url]http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html[/url], right?
>
>[/color]

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.
[color=blue]
>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.
>
>[/color]

Ok, no pressure... ;-)
[color=blue]
>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.
>
>[/color]

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

Might find some 64-bit issues, too.

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

Hmm... it would be nice to use USB's plug-n-play capabilities to detect
and autoconfigure it.
[color=blue]
>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
>[url]http://ntp.isc.org/bugs[/url] .
>
>[/color]

Done:

[url]https://ntp.isc.org/bugs/show_bug.cgi?id=699[/url]
[color=blue]
>H
>
>
>
>[/color]

_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

Danny Mayer wrote:
[color=blue]
>Harlan Stenn wrote:
>
>[color=green]
>>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.
>>
>>
>>[/color]
>
>Multicast works fine in 4.2.2. The changes to the interface code should
>not affect this. If it did, it would be a bug.
>
>Danny
>
>[/color]


What would I need to do to document if it is a bug? What would the smoking
gun be?

I've got 4.2.2p3 building, but with some funky patches rolled over from the
FC5 distro of 4.2.0a. I'm not sure what is necessary... and the weak type
checking of K&R C lets you do some braindead things without any warnings.

I'll try building it without those patches and see if it makes any
difference.

-Philip

_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

Harlan Stenn wrote:
[color=blue]
>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.
>
>[/color]

After a cursory stare (that's what that blinking thing was!) at the
code, I was wondering
why there's some duplication of macros, external declarations, and even
function
definitions (like doquery()).

I didn't have a chance yet to do a side-by-side comparison of the two
versions of the
function, but I'm wondering if we might be better off coming up with a
library that
provides both client and server functionality and then just having both
the server
and the utilities link against it.

Maybe moving declarations and macros (like P()) into a common header as
well.

I was trying to clean up some warnings with doquery(), and only hit one
of the
places it was declared... which caused a conflicting definition in the
other place
it was declared... Life is a lot simpler when functions are declared in
one and
only one place, and defined in one and only one place... especially when
your
compiler doesn't have strict prototypes.

I might try to compile with -std=c99 just for fun...

-Philip

_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

>>> In article <44FEF02A.6070908@redfish-solutions.com>, [email]philipp_subx@redfish-solutions.com[/email] (Philip Prindeville) writes:

H> We have made changes to the interface code since 4.2.2 - I recommend you
H> get the latest ntp-dev tarball and start with it. Please note that we
H> are about to start the countdown to the 4.2.4 release and I would very
H> much like to have a resolution to the issues you are seeing ASAP. If it
H> doesn't happen in time for 4.2.4, I am planning to have the next release
H> of NTP appear 6-8 months after 4.2.2.

D> Multicast works fine in 4.2.2. The changes to the interface code should
D> not affect this. If it did, it would be a bug.

Philip> What would I need to do to document if it is a bug? What would the
Philip> smoking gun be?

I suspect if you see unexpected/unwelcome behavior you can call that a bug
and document it to the best of your ability. The better the documentation,
the easier it will be to find the root cause.

Philip> I've got 4.2.2p3 building, but with some funky patches rolled over
Philip> from the FC5 distro of 4.2.0a. I'm not sure what is necessary...

Me either, and it would be far better if these problems were reported to us,
or if they picked up a 4.2.2 release and decided what patches are still
useful.

Philip> and the weak type checking of K&R C lets you do some braindead
Philip> things without any warnings.

Yes, which is why we enable a bunch of different warnings when we detect we
are building with gcc.

Feel free to edit any of:

- configure.ac
- configure
- config.status
- any Makefile

to include whatever warnings you want for your compiler.

I am also happy to consider adding different warning options based on the
detectable version of the compiler we are using.

Philip> I'll try building it without those patches and see if it makes any
Philip> difference.

Sounds good - if they are really fixing problems I would like to know what
they are.

H

>>> In article <44FEF4CC.7080104@redfish-solutions.com>, [email]philipp_subx@redfish-solutions.com[/email] (Philip Prindeville) writes:

Philip> Harlan Stenn wrote: why not just change the prototype of doquery(),
Philip> for instance?[color=blue][color=green]
>>[/color][/color]
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...

I do not know the line in question, and whenever I added a cast it was
specifically to shut up a warning.

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?)

And while I am hoping we will (very) soon drop the K&R requirement and go to
ANSI C, I suspect we are still talking about a base level that could be
simply ANSI C, as opposed to something like C99.

Philip> After a cursory stare (that's what that blinking thing was!) at the
Philip> code, I was wondering why there's some duplication of macros,
Philip> external declarations, and even function definitions (like
Philip> doquery()).

Probably leftover cruft.

Philip> I didn't have a chance yet to do a side-by-side comparison of the
Philip> two versions of the function, but I'm wondering if we might be
Philip> better off coming up with a library that provides both client and
Philip> server functionality and then just having both the server and the
Philip> utilities link against it.

Sometimes there was a slight difference between a function used by ntpd and
one used by ntpdc and/or ntpq (for example).

Yes, it would be Wonderful to simplify and fix these things.

Philip> Maybe moving declarations and macros (like P()) into a common header
Philip> as well.

Believe it or not, I made great strides in doing this very thing. I suspect
the job was never finished as I'm sure I was presented with other problems
that were more important to fix.

Philip> I was trying to clean up some warnings with doquery(), and only hit
Philip> one of the places it was declared... which caused a conflicting
Philip> definition in the other place it was declared... Life is a lot
Philip> simpler when functions are declared in one and only one place, and
Philip> defined in one and only one place... especially when your compiler
Philip> doesn't have strict prototypes.

Agreed, and I would happily accept patches to fix these problems. One of
the issues, however, is that there are a large number of compilers (and
system header files) out there, and there have been times before where
patches to "clean lint" on one version of an OS completely break the build
on some other OS.

Philip> I might try to compile with -std=c99 just for fun...

I'd be happy to work with you to see the code cleaned up.

H

Got:

[url]http://download.fedora.redhat.com/pub/fedora/linux/core/development/source/SRPMS/ntp-4.2.2p1-3.src.rpm[/url]

built it and installed it. It seems to fix the multicast volley issue.

Noticed that some of the patches correspond to proposed fixes in
bugzilla that have yet to be committed into the trunk.

-Philip

_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]

Philip Prindeville wrote:[color=blue][color=green]
>> Multicast works fine in 4.2.2. The changes to the interface code should
>> not affect this. If it did, it would be a bug.
>>
>> Danny
>>[/color]
>
> What would I need to do to document if it is a bug? What would the smoking
> gun be?
>[/color]

If something doesn't work, it's a bug. You may be doing something wrong
but it's better to report the problem so we can figure out if it's a
bug. Most smoking bugs aren't obvious except for the cigarette dangling
from their lips.

Danny
_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]