Multicast and dynamic interfaces - NTP

This is a discussion on Multicast and dynamic interfaces - NTP ; Moin, ntp-dev-4.2.5p118, Linux latest-ish. Also observed with ntp-dev-4.2.5p113 Should ntpd be able to listen for multicasts on interfaces that get added/configured after ntpd starts? For example, I just brought up and configured this interface: Jul 9 21:12:46 localhost ntpd[3422]: Listening ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Multicast and dynamic interfaces

  1. Multicast and dynamic interfaces

    Moin,

    ntp-dev-4.2.5p118, Linux latest-ish. Also observed with ntp-dev-4.2.5p113


    Should ntpd be able to listen for multicasts on interfaces that
    get added/configured after ntpd starts?

    For example, I just brought up and configured this interface:
    Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #8 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled
    Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #9 eth3, 172.27.72.99#123 Enabled

    However I'm not able to get it to hear the multicast data which
    can be heard, no matter how long I wait, unless I restart ntpd,
    like so:

    Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #3 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled
    Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
    Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #5 eth3, 172.27.72.99#123 Enabled
    Jul 9 21:15:43 localhost ntpd[19791]: Listening on interface #6 multicast, 224.0.1.1#123 Enabled
    Jul 9 21:15:43 localhost ntpd[19791]: setsockopt IP_ADD_MEMBERSHIP failure: No Jul 9 21:15:43 localhost ntpd[19791]: Failed to add Multicast Listener 224.0.1.1
    (no big deal that)
    Jul 9 21:15:43 localhost ntpd[19791]: Listening on interface #7 multicast, ff05::101#123 Enabled
    Jul 9 21:15:43 localhost ntpd[19791]: Added Multicast Listener ff05::101 on interface #7 multicast


    And voila, now I can hear and use that multicast data...
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    fe80::200:c0ff: .DCFa. 1 m 14 16 200 0.741 1.240 0.008


    Is this a case of missing or non-functioning code, or is this
    something that really isn't possible?


    thanks,
    barry bouwsma

  2. Re: Multicast and dynamic interfaces

    barry bouwsma wrote:
    > Moin,
    >
    > ntp-dev-4.2.5p118, Linux latest-ish. Also observed with ntp-dev-4.2.5p113
    >
    >
    > Should ntpd be able to listen for multicasts on interfaces that
    > get added/configured after ntpd starts?
    >


    Is this a common enough situation to justify the coding effort required?
    It seems to me to be a hell of a lot easier just to configure all your
    interfaces, or at least all you want to use, BEFORE starting ntpd!

    For that matter, doesn't ntpq or ntpdc allow you to configure the
    interface on the fly?


  3. Re: Multicast and dynamic interfaces


    >> Should ntpd be able to listen for multicasts on interfaces that
    >> get added/configured after ntpd starts?


    >Is this a common enough situation to justify the coding effort required?
    >It seems to me to be a hell of a lot easier just to configure all your
    >interfaces, or at least all you want to use, BEFORE starting ntpd!


    Yes. Wireless interfaces come and go all the time.

    The code to notice interfaces that get added or deleted is
    there already, at least in ntp-dev. If it doesn't work with
    multicast, it's probably worth the effort to fix it.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  4. Re: Multicast and dynamic interfaces

    barry bouwsma wrote:
    > Moin,
    >
    > ntp-dev-4.2.5p118, Linux latest-ish. Also observed with ntp-dev-4.2.5p113
    >
    >
    > Should ntpd be able to listen for multicasts on interfaces that
    > get added/configured after ntpd starts?
    >
    > For example, I just brought up and configured this interface:
    > Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #8 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled
    > Jul 9 21:12:46 localhost ntpd[3422]: Listening on interface #9 eth3, 172.27.72.99#123 Enabled
    >
    > However I'm not able to get it to hear the multicast data which
    > can be heard, no matter how long I wait, unless I restart ntpd,
    > like so:
    >
    > Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #3 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled
    > Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
    > Jul 9 21:15:42 localhost ntpd[19791]: Listening on interface #5 eth3, 172.27.72.99#123 Enabled
    > Jul 9 21:15:43 localhost ntpd[19791]: Listening on interface #6 multicast, 224.0.1.1#123 Enabled
    > Jul 9 21:15:43 localhost ntpd[19791]: setsockopt IP_ADD_MEMBERSHIP failure: No Jul 9 21:15:43 localhost ntpd[19791]: Failed to add Multicast Listener 224.0.1.1
    > (no big deal that)
    > Jul 9 21:15:43 localhost ntpd[19791]: Listening on interface #7 multicast, ff05::101#123 Enabled
    > Jul 9 21:15:43 localhost ntpd[19791]: Added Multicast Listener ff05::101 on interface #7 multicast
    >
    >
    > And voila, now I can hear and use that multicast data...
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > fe80::200:c0ff: .DCFa. 1 m 14 16 200 0.741 1.240 0.008
    >
    >
    > Is this a case of missing or non-functioning code, or is this
    > something that really isn't possible?


    It sounds like a bug, possibly 2 bugs. Please file a bug report. The
    multicast option should reconfigure itself after a change of IP address
    and rebind itself to the new address. If the address has gone away then
    the multicast socket won't be able to receive any multicast packets. Are
    you using DHCP provided addresses or static ones?

    Danny

  5. Re: Multicast and dynamic interfaces

    Sorry for line-mangling...

    --- On Fri, 7/11/08, Danny Mayer wrote:

    > > Should ntpd be able to listen for multicasts on

    > interfaces that
    > > get added/configured after ntpd starts?


    > > For example, I just brought up and configured this

    > interface:
    > > Jul 9 21:12:46 localhost ntpd[3422]: Listening on

    > interface #8 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled
    > > Jul 9 21:12:46 localhost ntpd[3422]: Listening on

    > interface #9 eth3, 172.27.72.99#123 Enabled


    > > Is this a case of missing or non-functioning code, or

    > is this
    > > something that really isn't possible?


    > It sounds like a bug, possibly 2 bugs. Please file a bug
    > report. The
    > multicast option should reconfigure itself after a change
    > of IP address
    > and rebind itself to the new address. If the address has
    > gone away then
    > the multicast socket won't be able to receive any
    > multicast packets. Are
    > you using DHCP provided addresses or static ones?


    This is a case of connecting after boot a USB ethernet adapter
    and manually assigning an IP address based on to which net I'm
    attaching myself and with which machines I wish to speak (though
    that shouldn't matter for multicast).

    I've also seen the same when I've manually reconfigured a WLAN
    interface to associate with a different network, over which I
    broadcast the name quoted multicast that I'm trying to hear via
    the USB adapter above.

    The IPv6 multicast seems to require no user intervention, either
    thanks to, in my case, the Linux kernel, or something else, while
    I have to set the route to 224.x.x.x in order for IPv4 multicast
    to be received. In the example I posted, I had failed to set
    that route before restarting ntpd, while the IPv6 m'cast was heard
    loud and clear, and the needed handshake took place.

    I start ntpd at boot; network configuration takes place later (WLAN
    depending on to which network I wish to associate, not all of which
    have NTP m'casts) by hand, though I've a template at boot that sets
    most ifconfig needed for IP address and such (interface doesn't go
    RUNNING until I actually associate with a particular WLAN).


    Hmm, maybe I need to test if the WLAN interface, which has the IPv6
    ff00::/8 route on it, can pick up m'cast after switching WLANs...
    Nope, didn't help


    thanks,
    barry bouwsma

  6. Re: Multicast and dynamic interfaces

    barry bouwsma wrote:
    > Sorry for line-mangling...
    >
    > --- On Fri, 7/11/08, Danny Mayer wrote:
    >
    >>> Should ntpd be able to listen for multicasts on

    >> interfaces that
    >>> get added/configured after ntpd starts?

    >
    >>> For example, I just brought up and configured this

    >> interface:
    >>> Jul 9 21:12:46 localhost ntpd[3422]: Listening on

    >> interface #8 eth3, fe80::200:e8ff:fe00:fe0#123 Enabled
    >>> Jul 9 21:12:46 localhost ntpd[3422]: Listening on

    >> interface #9 eth3, 172.27.72.99#123 Enabled

    >
    >>> Is this a case of missing or non-functioning code, or

    >> is this
    >>> something that really isn't possible?

    >
    >> It sounds like a bug, possibly 2 bugs. Please file a bug
    >> report. The
    >> multicast option should reconfigure itself after a change
    >> of IP address
    >> and rebind itself to the new address. If the address has
    >> gone away then
    >> the multicast socket won't be able to receive any
    >> multicast packets. Are
    >> you using DHCP provided addresses or static ones?

    >
    > This is a case of connecting after boot a USB ethernet adapter
    > and manually assigning an IP address based on to which net I'm
    > attaching myself and with which machines I wish to speak (though
    > that shouldn't matter for multicast).
    >
    > I've also seen the same when I've manually reconfigured a WLAN
    > interface to associate with a different network, over which I
    > broadcast the name quoted multicast that I'm trying to hear via
    > the USB adapter above.
    >
    > The IPv6 multicast seems to require no user intervention, either
    > thanks to, in my case, the Linux kernel, or something else, while
    > I have to set the route to 224.x.x.x in order for IPv4 multicast
    > to be received. In the example I posted, I had failed to set
    > that route before restarting ntpd, while the IPv6 m'cast was heard
    > loud and clear, and the needed handshake took place.
    >
    > I start ntpd at boot; network configuration takes place later (WLAN
    > depending on to which network I wish to associate, not all of which
    > have NTP m'casts) by hand, though I've a template at boot that sets
    > most ifconfig needed for IP address and such (interface doesn't go
    > RUNNING until I actually associate with a particular WLAN).
    >
    >
    > Hmm, maybe I need to test if the WLAN interface, which has the IPv6
    > ff00::/8 route on it, can pick up m'cast after switching WLANs...
    > Nope, didn't help
    >


    It's almost certainly a bug. It should always be able to associate the
    multicast address with the correct local address and it needs to be
    reassociated if the local address changes or is not there in the first
    place.

    Danny
    >
    > thanks,
    > barry bouwsma


+ Reply to Thread