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

This is a discussion on Issues w/ 4.2.0a, multicast,and porting 4.2.2 to Fedora Core - NTP ; 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. ...

+ Reply to Thread
Results 1 to 11 of 11

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

  1. 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:

    http://www.cis.udel.edu/~mills/ntp/h.../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)
    ....



    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: Issues w/ 4.2.0a, multicast, and porting 4.2.2 to Fedora Core

    Hi Philip,

    >>> In article <44FB0C3B.9000406@redfish-solutions.com>, philipp_subx@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?

    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/...lticastServers

    and

    http://ntp.isc.org/bin/view/Support/...lticastClients

    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 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:

    http://ntp.isc.org/Support/ConfiguringGarminRefclocks

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

    H

  3. Re: Issues w/ 4.2.0a, multicast, and porting4.2.2 to Fedora Core

    Harlan Stenn wrote:
    > 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.
    >


    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  4. Re: Issues w/ 4.2.0a, multicast, and porting 4.2.2to Fedora Core

    Philip Prindeville wrote:
    > 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.


    No you haven't, see below.

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


    You need to use 4.2.2 as there were a large number of fixes to get
    multicast working properly.

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


    I cannot imagine why it would not build. What are the errors you get
    during the build?

    > Anyway, I noticed the following. When I configure an FC5 machine with:
    >
    > ...
    > multicastclient # listen on default 224.0.1.1


    This is invalid. multicastclient requires an address, in this case
    224.0.1.1. You should be seeing an error message in syslog.

    > 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


    You don't need these lines unless you are providing ntp service to other
    systems.

    >
    >
    > And run ntpd with the arguments:
    >
    > ntpd -A -m -u ntp:ntp -p /var/run/ntpd.pid -g
    >


    As near as I can figure out -m is not a valid option.

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


    See above.

    > I've attached packet traces below.
    >
    > Is there a reason that ntpd isn't just synchronizing with the mulicast packets
    > instead?
    >


    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  5. Re: Issues w/ 4.2.0a, multicast, and porting4.2.2 to Fedora Core

    Harlan Stenn wrote:

    >Hi Philip,
    >
    >
    >
    >>>>In article <44FB0C3B.9000406@redfish-solutions.com>, philipp_subx@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/...lticastServers
    >
    >and
    >
    > http://ntp.isc.org/bin/view/Support/...lticastClients
    >
    >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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: Issues w/ 4.2.0a, multicast, and porting4.2.2 to Fedora Core

    Danny Mayer wrote:

    >Harlan Stenn wrote:
    >
    >
    >>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.
    >>
    >>
    >>

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



    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  7. Re: Issues w/ 4.2.0a, multicast, and porting4.2.2 to Fedora Core

    Harlan Stenn wrote:

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


    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  8. Re: Issues w/ 4.2.0a, multicast, and porting 4.2.2 to Fedora Core

    >>> In article <44FEF02A.6070908@redfish-solutions.com>, philipp_subx@redfish-solutions.com (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

  9. Re: Issues w/ 4.2.0a, multicast, and porting 4.2.2 to Fedora Core

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

    Philip> Harlan Stenn wrote: why not just change the prototype of doquery(),
    Philip> 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...

    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


  10. Re: Issues w/ 4.2.0a, multicast, and porting4.2.2 to Fedora Core

    Got:

    http://download.fedora.redhat.com/pu....2p1-3.src.rpm

    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  11. Re: Issues w/ 4.2.0a, multicast, and porting4.2.2 to Fedora Core

    Philip Prindeville wrote:
    >> 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
    >>

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


    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


+ Reply to Thread