Ubuntu
network-manager package

Constant _ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed messages in syslog

Bug #996032 reported by Neil Wilson
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
network-manager (Fedora)
Fix Released
Low
network-manager (Ubuntu)
Fix Released
Low
Unassigned
Precise
Fix Released
Low
Mathieu Trudel-Lapierre

Bug Description

[Impact]
Causes extra messages to spam syslog on every address addition netlink message, or every route change. (Very often)
No actual behavioral impact aside from a log which is potentially very rapidly growing due to these warning messages.

[Test Case]
This requires an Apple Airport device connected in IPv6 tunneling mode.
1) Connect the computer to the Airport device's network.

You should see IN6_ARE_ADDR_EQUAL assertions without the patch, and no such messages with the patch applied.

[Regression Potential]
Changes testing logic for IP address comparison to return silently rather than asserting (because assertions cause the messages to be printed to syslog); so no actual impact on that side except for the messages not being printed out.
However, this introduces duplicates checking for the routes and addresses as well, which has a small potential for extra routes to be missing if the duplicate checking fails to consider extra flags which would make the similar-looking routes or addresses actually very different.

----

When both the Ethernet and wlan are connected to an Apple Airport running IPv6.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.4.0-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CRDA:
 country GB:
  (2402 - 2482 @ 40), (N/A, 20)
  (5170 - 5250 @ 40), (N/A, 20)
  (5250 - 5330 @ 40), (N/A, 20), DFS
  (5490 - 5710 @ 40), (N/A, 27), DFS
CheckboxSubmission: 55cafa5b8b82ed224cc59d444cb1fc25
CheckboxSystem: 3e53d3ea5811723345f19eff5070f9ab
Date: Mon May 7 17:31:00 2012
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
IpRoute:
 default via 192.168.0.1 dev eth0 proto static
 169.254.0.0/16 dev eth0 scope link metric 1000
 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.112 metric 1
 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.108 metric 2
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to precise on 2012-05-07 (0 days ago)
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 Apple Network ad3977 6e164836-7615-41dd-b5bb-d76c15a3d43c 802-11-wireless 1336408221 Mon 07 May 2012 17:30:21 BST yes no /org/freedesktop/NetworkManager/Settings/2
 Ethernet 8d5e9b11-7cd5-4f58-a0fd-3f3cbea16909 802-3-ethernet 1336408221 Mon 07 May 2012 17:30:21 BST yes no /org/freedesktop/NetworkManager/Settings/1
 Brightbox 92ea9b57-86a6-4867-b825-5c8278657559 vpn 1336407670 Mon 07 May 2012 17:21:10 BST no no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth0 802-3-ethernet connected /org/freedesktop/NetworkManager/Devices/1
 wlan0 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.4.0 connected enabled enabled enabled enabled disabled

See original description
Revision history for this message
Neil Wilson (neil-aldur) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Andrew (andrew-redhat-bugs) wrote :
Download full text (5.7 KiB)

Description of problem:
This is a wired ethernet network. Is connected to an Apple airport with IPv6 tunneling turned on; the tunneling is provided by Comcast/Xfinity.

While the network seems to work okay (including ipv6.google.com), journald is filled up with this representative sample:

May 10 10:39:35 mithos.talinet.net dnsmasq[997]: reading /etc/resolv.conf
May 10 10:39:35 mithos.talinet.net dnsmasq[997]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 10 10:39:35 mithos.talinet.net dnsmasq[997]: using nameserver 10.0.1.1#53
May 10 10:39:35 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:40:31 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:41:18 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:41:18 mithos.talinet.net NetworkManager[787]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 10 10:41:18 mithos.talinet.net NetworkManager[787]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 10 10:41:18 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:41:27 mithos.talinet.net dnsmasq[997]: reading /etc/resolv.conf
May 10 10:41:27 mithos.talinet.net dnsmasq[997]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 10 10:41:27 mithos.talinet.net dnsmasq[997]: using nameserver 10.0.1.1#53
May 10 10:41:27 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:43:31 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:44:26 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:44:26 mithos.talinet.net NetworkManager[787]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 10 10:44:26 mithos.talinet.net NetworkManager[787]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 10 10:44:26 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:45:11 mithos.talinet.net dnsmasq[997]: reading /etc/resolv.conf
May 10 10:45:11 mithos.talinet.net dnsmasq[997]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 10 10:45:11 mithos.talinet.net dnsmasq[997]: using nameserver 10.0.1.1#53
May 10 10:45:11 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[i]) == FALSE' failed
May 10 10:45:17 mithos.talinet.net NetworkManager[787]: nm_ip6_config_add_nameserver: assertion `IN6_ARE_ADDR_EQUAL (nameserver, &nameservers[...

Read more...

Revision history for this message
In , Andrew (andrew-redhat-bugs) wrote :

Created attachment 583945
NetworkManager Debug log

Turned on debug logging on NetworkManager and captured the output.

Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

OK, so the problem is that your IPv6 tunnel is telling you it has 2 IPv6 nameservers, but it's just actually the same server listed twice, which NM wasn't expecting and so it does something dumb, causing the warning.

Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

Created attachment 584407
patch

Revision history for this message
In , Andrew (andrew-redhat-bugs) wrote :
Download full text (4.0 KiB)

Created attachment 584453
New debug log, NetworkManager.service only

I applied the patch against the upstream NetworkManager 0e262e04e1800f312d4c40c07b6394ffacb2d34d.

While there are no assertions as expected, there is still something screwy going on causing a repetative reconfiguration, shown below. I've also attached the output of journalctl _SYSTEMD_UNIT=NetworkManager.service although it looks to be relatively the same as the previous log.

I've also noticed that this isn't a problem when the IPv6 configuration is set to 'DHCP only', but that's probably expected.

May 14 12:10:49 mithos.talinet.net dnsmasq[796]: reading /etc/resolv.conf
May 14 12:10:49 mithos.talinet.net dnsmasq[796]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 14 12:10:49 mithos.talinet.net dnsmasq[796]: using nameserver 10.0.1.1#53
May 14 12:11:18 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 14 12:11:18 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 14 12:14:24 mithos.talinet.net dnsmasq[796]: reading /etc/resolv.conf
May 14 12:14:24 mithos.talinet.net dnsmasq[796]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 14 12:14:24 mithos.talinet.net dnsmasq[796]: using nameserver 10.0.1.1#53
May 14 12:14:28 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 14 12:14:28 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 14 12:14:36 mithos.talinet.net dnsmasq[796]: reading /etc/resolv.conf
May 14 12:14:36 mithos.talinet.net dnsmasq[796]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 14 12:14:36 mithos.talinet.net dnsmasq[796]: using nameserver 10.0.1.1#53
May 14 12:14:36 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 14 12:14:36 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 14 12:14:36 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 14 12:14:36 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 14 12:14:37 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 14 12:14:37 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 14 12:15:19 mithos.talinet.net dnsmasq[796]: reading /etc/resolv.conf
May 14 12:15:19 mithos.talinet.net dnsmasq[796]: using nameserver 2002:62f4:3669:0:21e:52ff:fef1:811a#53
May 14 12:15:19 mithos.talinet.net dnsmasq[796]: using nameserver 10.0.1.1#53
May 14 12:16:05 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv4 routing and DNS.
May 14 12:16:05 mithos.talinet.net NetworkManager[651]: <info> Policy set 'System p5p1' (p5p1) as default for IPv6 routing and DNS.
May 14 12:...

Read more...

Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

(In reply to comment #4)
> Created attachment 584453 [details]
> New debug log, NetworkManager.service only
>
> I applied the patch against the upstream NetworkManager

Oh! Cool, I was just putting it here for the other maintainers to look at. :)

> While there are no assertions as expected, there is still something screwy
> going on causing a repetative reconfiguration

Oh, yeah, it wasn't expected to change that; for some reason, your IPv6 tunnel is configured to send out router advertisements extremely frequently. So each time it gets one, NM checks the data in it to see if anything changed since the last one. I guess we're not checking whether we actually need to update dnsmasq or not, so it's getting "updated" even when nothing changed.

Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

Pavel, see above; another thing to look at in your NMIP6Manager fixes (we're apparently emitting config-changed on RDNSS announcements even when nothing changed, resulting in unnecessary syslog spew)

Revision history for this message
In , Dan (dan-redhat-bugs) wrote :

fixed in git. since it doesn't actually affect functionality, I'm not going to worry about getting it into F17

Revision history for this message
In , Pavel (pavel-redhat-bugs) wrote :

Thank you, Dan. I'll look into it.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

NetworkManager-0.9.4.0-9.git20120521.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.4.0-9.git20120521.fc17

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

NetworkManager-0.9.4-6.git20120521.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.4-6.git20120521.fc16

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

NetworkManager-0.9.4-6.git20120521.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

NetworkManager-0.9.4.0-9.git20120521.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Fixed by upstream commit cca4052 -- that could be a candidate for SRU; the patch is small but impact is important.

Are you still seeing this issue? Does it happen often? It seems as though it would be caused by duplicate IPv6 nameservers; that's fixable on the network as well as within NetworkManager.

Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
importance: Undecided → Low
Changed in network-manager (Ubuntu Precise):
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Neil Wilson (neil-aldur) wrote :

It happens ever time. My v6 nameserver is issued by an Apple Airport operating in tunnel mode. There is only a single nameserver issued and it is the address of the Airport (much as the v4 nameserver is the address of the Airport).

The RA issued by the router has a single recursive DNS entry in it.

I'm also seeing the Ubuntu machine issue a 'port unreachable' ICMPv6 message to any v6 DNS responses.

So the Ubuntu issues DNS query to port 53 over v6.
The router responds back to the UDP source port
Ubuntu then issues a 'port unreachable' ICMPv6 message.

I'm not seeing that on the parallel v4 query.

Mathieu Trudel-Lapierre (cyphermox)
Changed in network-manager (Ubuntu Precise):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Adding the upsteam bug; it's much more obvious to see that the patch fixes this issue from the RH bug than the commit message.

Changed in network-manager (Ubuntu Precise):
status: Triaged → In Progress
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Commit URL: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=cca40524ac108eec7ca0337b02b52f1eb0f37b0c

I'm preparing the upload now with a few other fixes.

Mathieu Trudel-Lapierre (cyphermox)
description: updated
Revision history for this message
Chris Halse Rogers (raof) wrote : Please test proposed package

Hello Neil, or anyone else affected,

Accepted network-manager into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/network-manager/0.9.4.0-0ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in network-manager (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Neil Wilson (neil-aldur) wrote :

Tested, and it clears the log message in this bug.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Robin Smidsrød (robinsmidsrod) wrote :

I just want to add a comment that the reason for the problem itself is that both the IPv4 and IPv6 stacks receive a pointer to the same DNS server using both an IPv4 address and an IPv6 address.

Once I disabled IPv6 name servers in both radvd and isc-dhcp-server6 configurations and only used an IPv4 address to point to the DNS server the error disappeared from my logs. Not having IPv6 DNS servers will obviously affect IPv6-only clients.

I would argue that pointing to the same DNS server using both IPv4 and IPv6 on a dualstack machine is the correct thing to do, so the message shouldn't really trigger any error. I'm not sure how the DNS server is determined to be the same, I'm assuming ARP or some identifier sent from the DNS server validates that claim. If so, the simple workaround might be to return a different identifier from the DNS server based on IPv4 or IPv6 connection.

Revision history for this message
Colin Watson (cjwatson) wrote : Update Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.9.4.0-0ubuntu4.2

---------------
network-manager (0.9.4.0-0ubuntu4.2) precise-proposed; urgency=low

  * debian/patches/git_use_wpa_wext_methods_50435e1.patch: use the same kind
    of logic as wpasupplicant instead of just looking at whether a driver
    reports signal over nl80211 to decide whether to use that or fallback
    to wext. (LP: #1035590)
  * debian/patches/ipw2x00-no-nl80211.patch: replaced by the patch above.
  * debian/patches/git_ignore_ipconfig_dups_cca4052.patch: silently ignore
    duplicates in NMIP[46]Config objects; which tends to happen fairly
    regularly with RDNSS. (LP: #996032)
  * debian/patches/nm-ipv6-route-cache.patch: don't re-add routes we receive
    from kernel notifications to the routing table if they have the
    RTM_F_CLONED flag; since that means they're host routes used temporarily
    by the kernel to reach a specific destination; keeping them would cause at
    least issues with VPNs, and possibly confusion with routing daemons.
    Thanks to Ben Jenks for the patch. (LP: #1038541)
  * debian/ifblacklist_migrate.sh: make sure that "iface X inet6" entries added
    by d-i also get commented out if set up for dhcp or auto -- this follows
    what is already done for IPv4, where such devices should be handled by
    NetworkManager. This fixes issues where people installing using d-i and
    where IPv6 autoconfiguration is available would get their interfaces
    ignored by NetworkManager when installing desktop. (LP: #995165)
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 10 Oct 2012 17:31:55 -0400

Changed in network-manager (Ubuntu Precise):
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in network-manager (Fedora):
importance: Unknown → Low
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.