ntpd deletes IPv6 interface after startup - NTP

This is a discussion on ntpd deletes IPv6 interface after startup - NTP ; Hello. After updating from 4.2.0a to 4.2.4p4, I experience some problems getting the IPv6 interface to work again. It did work with 4.2.0a. ntpd initializes the interface at startup and then deletes it immediately afterwards. I tracked the problem down ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: ntpd deletes IPv6 interface after startup

  1. ntpd deletes IPv6 interface after startup

    Hello.

    After updating from 4.2.0a to 4.2.4p4, I experience some problems getting
    the IPv6 interface to work again. It did work with 4.2.0a.

    ntpd initializes the interface at startup and then deletes it immediately
    afterwards. I tracked the problem down to update_interfaces() in ntp_io.c
    where the interfaceiter in phase I skips the 6-to-4 interface (and others)
    the second and further times the function is called. Thus the interface
    structure's phase field is not updated and phase II marks the interface as
    "GONE" and deletes it.

    I haven't found out why the iterator skips the interfaces, yet. Doesn't it
    always use the same set of interfaces returned by getifaddrs()?

    I saved debug output from the first and second call to update_interfaces()
    here:

    http://tinyurl.com/2khp5k

    As a workaround, I disabled interface updates (-U 0) and now ntpd keeps
    listening on all interfaces.



    Hauke.

  2. Re: ntpd deletes IPv6 interface after startup

    Hauke,

    your observation seem correct. I have no idea why the ifiter code
    skips IPv6 interfaces on the second round. There seems to be a bug
    there. ifiter must return the complete currently valid interface list or
    the interface scanning code will not work correctly.
    Have you checked via ifconfig -a that the interface are still listed
    when ifiter fails to enumerate them ?

    Please file a bug at http://bugs.ntp.org. Be sure to include detailed
    information about your operating system.

    Hauke Lampe wrote:
    > Hello.
    >
    > After updating from 4.2.0a to 4.2.4p4, I experience some problems getting
    > the IPv6 interface to work again. It did work with 4.2.0a.

    4.2.0a only did the first scan - - no surprise that it worked there.

    >
    > ntpd initializes the interface at startup and then deletes it immediately
    > afterwards. I tracked the problem down to update_interfaces() in ntp_io.c
    > where the interfaceiter in phase I skips the 6-to-4 interface (and others)
    > the second and further times the function is called. Thus the interface
    > structure's phase field is not updated and phase II marks the interface as
    > "GONE" and deletes it.

    Correct analysis.
    >
    > I haven't found out why the iterator skips the interfaces, yet. Doesn't it
    > always use the same set of interfaces returned by getifaddrs()?

    It should - maybe its a porting issue or some other problem in the
    ifiter/getifaddrs area.

    >
    > I saved debug output from the first and second call to update_interfaces()
    > here:
    >
    > http://tinyurl.com/2khp5k
    >
    > As a workaround, I disabled interface updates (-U 0) and now ntpd keeps
    > listening on all interfaces.

    Yes, it only does the first and sucessful scan.
    >
    >
    >
    > Hauke.


    Frank

  3. Re: ntpd deletes IPv6 interface after startup

    Frank Kardel schrieb:

    > Have you checked via ifconfig -a that the interface are still listed
    > when ifiter fails to enumerate them ?


    Yes, the interface state has not changed since the last reboot. It's up and
    reachable from the outside.

    > Please file a bug at http://bugs.ntp.org. Be sure to include detailed
    > information about your operating system.


    I did a bit more research for a bug report.

    Due to a bug in my debugging output (d'Oh!), ntpd appeared to use
    getifaddrs while in fact it used ifiter_ioctl. As I understand it, glibc's
    getifaddrs() supports only IPv4 and libinet6 is not available on my system.

    By alternating configuration options, I found that the problem manifests
    only when ntpd chroots itself. I usually start ntpd with

    -u ntpd:ntpd -i /var/lib/ntp

    to chroot and drop root privileges after startup. Without the -i option,
    ntpd binds to all interfaces and keeps listening, whether or not it changes
    UID to user ntpd.

    After chroot, /proc/net/if_inet6 isn't available to ifiter_ioctl anymore.

    So, I don't think it's a real bug, although an unexpected nuisance.

    The options AFAIK see, are:

    - change ifiter_ioctl to enumerate IPv6 interfaces through a socket call as
    it does for IPv4. I don't know if that's even possible.
    - install libinet6 to enable getifaddrs(). This looks possible, but I'm not
    sure I really want to go there
    - don't use chroot
    - mount proc on /var/lib/ntp/proc
    - keep running with -U 0

    I'll stick with -U 0 for now as it doesn't seem to do any harm, even after
    I shut an interface down and brought it up again.

    Should I still file this as a bug?

    I added a note to
    http://support.ntp.org/bin/view/Supp...on_9.2.3.2.5.1.



    Hauke.

  4. Re: ntpd deletes IPv6 interface after startup

    Hi Hauke !

    Hauke Lampe wrote:
    > Frank Kardel schrieb:

    ....
    > I did a bit more research for a bug report.

    Thanks for digging into that.

    >
    > Due to a bug in my debugging output (d'Oh!), ntpd appeared to use
    > getifaddrs while in fact it used ifiter_ioctl. As I understand it, glibc's
    > getifaddrs() supports only IPv4 and libinet6 is not available on my system.
    >
    > By alternating configuration options, I found that the problem manifests
    > only when ntpd chroots itself. I usually start ntpd with
    >
    > -u ntpd:ntpd -i /var/lib/ntp
    >
    > to chroot and drop root privileges after startup. Without the -i option,
    > ntpd binds to all interfaces and keeps listening, whether or not it changes
    > UID to user ntpd.
    >
    > After chroot, /proc/net/if_inet6 isn't available to ifiter_ioctl anymore.
    >
    > So, I don't think it's a real bug, although an unexpected nuisance.


    Workarounds in the base code for all these environment induced OS API
    behavior changes would be hard.

    >
    > The options AFAIK see, are:
    >
    > - change ifiter_ioctl to enumerate IPv6 interfaces through a socket call as
    > it does for IPv4. I don't know if that's even possible.
    > - install libinet6 to enable getifaddrs(). This looks possible, but I'm not
    > sure I really want to go there


    The problem would be that the API interface used is determined at
    configure time - not at run time.

    > - don't use chroot
    > - mount proc on /var/lib/ntp/proc

    I think that would be a viable option - recreate the original
    environment. There may be security hazards though.

    > - keep running with -U 0

    That's the simplest solution if you are running in a static address
    environment.

    >
    > I'll stick with -U 0 for now as it doesn't seem to do any harm, even after
    > I shut an interface down and brought it up again.

    Keep in mind that ntpd sticks to the interface list it found at startup
    time.
    It will not discover any interface changes in the -U 0 mode. If it would
    be forced to do so (e.g. ntpdc -c ifreload) it would drop the IPv6
    interfaces again.

    >
    > Should I still file this as a bug?
    >

    Chances to fix Linux glibc/proc features in the base code are slim.

    > I added a note to
    > http://support.ntp.org/bin/view/Supp...on_9.2.3.2.5.1.


    That is a good action. Thanks for documenting that.

    Frank

+ Reply to Thread