ntp complains about ipv6 errors every 5 minutes

[John Kounis]

Binary package hint: ntp

Every 5 minutes, ntpd complains about being unable to create a socked on an ipv6 address. I'm running a new installation of Maverick 10.10. Here is my syslog:

Jan 8 04:05:01 pgfs ntpd[2608]: synchronized to 91.189.94.4, stratum 2
Jan 8 04:05:01 pgfs ntpd[2608]: kernel time sync status change 2001
Jan 8 04:05:42 pgfs ntpd[2608]: bind() fd 22, family AF_INET6, port 123, scope 4, addr fe80::217:31ff:fef8:f63f, mcast=0 flags=0x11 fails: Cannot assign requested address
Jan 8 04:05:42 pgfs ntpd[2608]: unable to create socket on bond0 (8) for fe80::217:31ff:fef8:f63f#123
Jan 8 04:05:42 pgfs ntpd[2608]: failed to initialize interface for address fe80::217:31ff:fef8:f63f
Jan 8 04:10:42 pgfs ntpd[2608]: bind() fd 22, family AF_INET6, port 123, scope 4, addr fe80::217:31ff:fef8:f63f, mcast=0 flags=0x11 fails: Cannot assign requested address
Jan 8 04:10:42 pgfs ntpd[2608]: unable to create socket on bond0 (9) for fe80::217:31ff:fef8:f63f#123
Jan 8 04:10:42 pgfs ntpd[2608]: failed to initialize interface for address fe80::217:31ff:fef8:f63f

I'm running ntp 1:4.2.4p8+dfsg-1ubuntu6.
FYI, here is the output of md5sum /usr/sbin/ntp*. I think these are the latest packages:

42415ef5eb851dabe9d06a67cf992d28 /usr/sbin/ntpd
c1d85ce075c70928b53692561fdc5277 /usr/sbin/ntpdate
79af988228131692520be14d25355a8e /usr/sbin/ntpdate-debian
d4ae7ee172f7ed340c4e1b406c04d16d /usr/sbin/ntp-keygen
b7f7e4e0fb1d4e2aece718b18ae28b46 /usr/sbin/ntptime
7d4b58d1da97ba46ba8eeab08b345a44 /usr/sbin/ntp-wait

This is a brand new installation. The sequence of steps to reproduce this are:

1. Install Maverick on a RAID 1 system. Separate / and /home partition.
2. Install Updates
3. Install graphics card hardware driver
4. Download ifenslave. Configure bonding. Set static IP address.
5. Install NTP

[James Page (james-page)]

Confirmed using the following setup:

qemu/libvirt vm running Maverick 10.10 i386 install; added two additional network adapters and then bonded eth1 and eth2 using a fairly standard bonding configuration (ifenslave as described above). ipv4 addressing works fine - however get the same error message as the original reporter when ntp tries to bond to the ipv6 link address on bond0:

Jan 20 13:22:23 maverick-triage ntpd[1496]: bind() fd 23, family AF_INET6, port 123, scope 5, addr fe80::5054:ff:feb4:db79, mcast=0 flags=0x11 fails: Cannot assign requested address
Jan 20 13:22:23 maverick-triage ntpd[1496]: unable to create socket on bond0 (8) for fe80::5054:ff:feb4:db79#123
Jan 20 13:22:23 maverick-triage ntpd[1496]: failed to initialize interface for address fe80::5054:ff:feb4:db79

[James Page (james-page)]

Also noticed that even without bonding I get the same message every 5 minutes from ntp (but on the eth0 interface).

This could be related to bug 697592.

[Jamie Strandboge (jdstrand)]

Are there any apparmor denied messages in kern.log for ntpd?

[James Page (james-page)]

Correction - this only happens when the address is in 'tentative' state; this resolves shortly after boot (see https://bugs.ntp.org/show_bug.cgi?id=1134)

[James Page (james-page)]

No apparmor denied messages in kern.log on my test VM.

[James Page (james-page)]

Hi John

I've been reviewing all IPv6 related bugs associated with NTP; although I could reproduce this in January I am now unable to get the same results.

Are you still seeing this issue? I'm aware that there is an upstream bug related to the interface being in a tentative state but that should resolve shortly after boot.

If you are still having problems details of your IPv6 setup and networking interface bonding configuration would be really helpful

Thanks

[Ludovico Cavedon (cavedon)]

I am currently having this issue, but it might not be an ntp bug, but rather a kernel bug.

If you assign an IPv6 address to a virtual device composed of real sub-devices (e.g. to a bonding or bridge interface), the address will be wrongly detected as duplicate (marked as "tentative dadfailed"). See
https://bugzilla.redhat.com/show_bug.cgi?id=503082

And this triggers the ntp messages because apparently ntp tries and fails to bind to the interface with the problematic address.

My workaround to this issue was not assigning an IPv6 address to my bridge interface (I realized that it was not really needed in my case).

[Serge Hallyn (serge-hallyn)]

(Setting importance to low since it has an easy workaround)

[Serge Hallyn (serge-hallyn)]

Marking Confirmed based on the linked bug reports.

However, the linked reports contradict each other. http://bugs.ntp.org/show_bug.cgi?id=1134 suggests a simple workaround in userspace. The redhat bug (and poster above) suggests there is a kernel bug. So I've marked this as also affecting kernel - please mark that invalid if appropriate.

[John Kounis (ubuntu-pilotgetaways)]

The problem does not resolve for me. I still get the following errors (uptime is >3 days):

Apr 27 22:01:44 pgfs ntpd[2535]: bind() fd 24, family AF_INET6, port 123, scope 4, addr fe80::217:31ff:fef8:f63f, mcast=0 flags=0x11 fails: Cannot assign requested address
Apr 27 22:01:44 pgfs ntpd[2535]: unable to create socket on bond0 (922) for fe80::217:31ff:fef8:f63f#123
Apr 27 22:01:44 pgfs ntpd[2535]: failed to initialize interface for address fe80::217:31ff:fef8:f63f
Apr 27 22:06:44 pgfs ntpd[2535]: bind() fd 24, family AF_INET6, port 123, scope 4, addr fe80::217:31ff:fef8:f63f, mcast=0 flags=0x11 fails: Cannot assign requested address
Apr 27 22:06:44 pgfs ntpd[2535]: unable to create socket on bond0 (923) for fe80::217:31ff:fef8:f63f#123
Apr 27 22:06:44 pgfs ntpd[2535]: failed to initialize interface for address fe80::217:31ff:fef8:f63f

Here is my /etc/network/interfaces. Note that I have 2 aliases on bond 0. I don't know if that matters:

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
address 10.11.12.4
netmask 255.255.255.0
network 10.11.12.0
broadcast 10.11.12.255
gateway 10.11.12.1
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1

auto bond0:0
iface bond0:0 inet static
address 10.11.12.5
netmask 255.255.255.0
network 10.11.12.0
broadcast 10.11.12.255

auto bond0:1
iface bond0:1 inet static
address 10.11.12.21
netmask 255.255.255.0
network 10.11.12.0
broadcast 10.11.12.255

[Tim Edwards (tkedwards)]

I can confirm that this bug is still present in 12.04 (new install, not an upgrade).

The workaround is to add the following to the end of /etc/ntp.conf and restart ntp:
# Prevent it flooding syslog with error messages:
interface ignore ipv6

(assuming that you're on an IPv4 network)

[penalvch (penalvch)]

John Kounis, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.