More on NetworkManager creating a new connection ‘eth0′ that does not work
March 17, 2015 4 Comments
In a previous post I described a problem I have been experiencing with NetworkManager since Version 0.9.10.0 (I am now using Version 1.0.0): sometimes, but not always, there is an invalid second eth0 connection when my laptop boots. This invalid second eth0 connection has only IPv6 Link-Local enabled (i.e. IPv4 and IPv6 are disabled) and is Active. As a result the existing eth0 connection for IPv4 I previously created is Available but unable to connect.
While on a work trip and using my laptop on an office network and an hotel network I made some changes to my installation (see the above-mentioned previous post) that seemed to fix this problem on those networks. However, on returning home and connecting my laptop to my home network, I found the problem still exists. This makes me wonder if a race condition is occurring, as network latency can differ between networks. Could it be that my home network takes longer to assign an IPv4 address than the office and hotel networks I used, which results in NetworkManager creating a second eth0 connection with IPv4 and IPv6 disabled? Or perhaps there is a race condition between services but network latency has nothing to do with it. In retrospect, I should have checked the contents of the log file
/var/log/messages while on my work trip to see if those networks were providing my laptop with an IPv6 address in addition to an IPv4 address, i.e. check if the IPv6 address was not just a Link-Local address.
But why is NetworkManager creating any additional connection at all when
NetworkManager.conf in my installation currently contains ‘
no-auto-default=eth0‘? Surely this must be a bug in NetworkManager?
I have found virtually no mention of this behaviour on the Web. Debian bug report no. 755202 appears to describe the same problem. I started experiencing the problem in Gentoo Linux (~amd64 installation using OpenRC) after I upgraded NetworkManager to Version 0.9.10.0 too, and it has continued occurring up to the current version of NetworkManager (1.0.0). Fellow Gentoo Linux user Keivan Moradi’s fix (Message #79 in the aforementioned Debian bug report) did not cure the problem for me, and, anyway, my wired NIC uses a different driver (
atl1c module) which appears to be stable in my installation.
CentOS bug report no. 0007435 also appears to report the same behaviour, but I’m not sure.
NetworkManager usually (but not always) creates an invalid second eth0 connection when my laptop boots and an Ethernet cable is connected to my home network. The second eth0 connection is shown as Active in plasma-nm (the KDE front-end for NetworkManager) but only has an IPv6 Link-Local connection configured (i.e. IPv4 is shown as Disabled). If I click on Disconnect in plasma-nm then this ‘rogue’ eth0 connection disappears from plasma-nm. Once the invalid IPv6 Link-Local connection has been disconnected, the valid IPv4 eth0 available connection can connect to the network and access the Internet.
/var/log/messages when the invalid second eth0 connection occurs and when it doesn’t, and the invalid eth0 connection only seems to occur when NetworkManager appears to have first started earlier than syslog-ng began logging. When NetworkManager first starts after syslog-ng began logging, I can see it launches dhcpcd and acquires an IPv4 address. avahi-daemon does not seem to be the cause of the problem if I understand the log file correctly. Anyway, my experiments described below seem to exonerate the Avahi daemon. I could be misinterpreting what is going on, but that’s how it looks to my inexpert eyes. In Debian bug report no. 755202 some commenters refer to extra interfaces with names such as ‘eth0:avahi’ being listed by the
ifconfig command when the problem occurs, but I wonder if that is just a side effect. Anyway, the
ifconfig command does not list such interfaces in my case.
I tried the following experiments:
1. I commented out the entire contents of the file
/etc/conf.d/net (the configuration file for initscripts
/etc/init.d/net.*) — which I think is analogous to Debian’s
/etc/network/interfaces file — but it did not stop the invalid second eth0 connection occurring.
2. I added ‘
use-ipv6=no‘ and, later, ‘
use-ipv4=no‘ in the file
/etc/avahi/avahi-daemon.conf but they did not stop the invalid second eth0 connection occurring.
3. I added ‘
deny-interfaces=eth0‘ in the file
/etc/avahi/avahi-daemon.conf but it did not stop the invalid second eth0 connection occurring.
4. In my installation, the ‘
local‘ service (launched by initscript
/etc/init.d/local) has always been allocated to two runlevels: ‘
default‘ and ‘
nonetwork‘. I de-allocated the ‘
local‘ service from the ‘
nonetwork‘ runlevel but this did not stop the invalid second eth0 connection occurring.
5. In my installation, the ‘
net.lo‘ service (launched by initscript
/etc/init.d/net.lo) has always been allocated to the ‘
boot‘ runlevel (the other
net.* services, such as ‘
net.eth0‘ and ‘
net.wlan0‘, have never been allocated to a runlevel in my installation). I de-allocated ‘
net.lo‘ from the ‘
boot‘ runlevel but it did not stop the invalid eth0 connection occurring.
As experiments 4 and 5 did not stop the laptop accessing the Internet once I had deleted the invalid second eth0 connection, I have left the ‘
local‘ service in the ‘
default‘ runlevel only, and I have left the ‘
net.lo‘ service unallocated to a runlevel.
6. Since the invalid eth0 connection is allocated an IPv6 Link-Local address rather than an IPv4 address on my home network, I tried a work-around: I disabled IPv6 system-wide by un-commenting the line ‘
alias net-pf-10 off‘ in the file
/etc/modprobe.d/aliases.conf. Now a second eth0 connection is no longer created, and the valid eth0 IPv4 connection I created previously connects automatically. I have not rebooted many times yet, so I don’t know if this work-around has eliminated the problem for good, but it looks promising.
Nevertheless I would like to find the root cause of the problem, rather than settling for a work-around of disabling IPv6 system-wide. Given that, when IPv6 is enabled, a second eth0 connection is sometimes not created and the ‘good’ IPv4 eth0 connection I created previously can connect, hopefully it should be possible somehow to have both IPv6 and IPv4 enabled system-wide without an invalid eth0 connection ever being created. Could NetworkManager be modified so that it does not create a connection if the DHCP client launched by NetworkManager does not obtain an IP address, for example?
This is not the end of the story, I’m sure.
For information, the services currently used are shown below:
The allocations of services to runlevels are shown below:
My installation has the following six runlevels: