More on NetworkManager creating a new connection ‘eth0′ that does not work
March 17, 2015 7 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.
I examined /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:
meshedgedx fitzcarraldo # rc-status --all
Runlevel: nonetwork
Runlevel: shutdown
killprocs [ stopped ]
savecache [ stopped ]
mount-ro [ stopped ]
Runlevel: sysinit
devfs [ started ]
tmpfiles.dev [ started ]
sysfs [ started ]
dmesg [ started ]
udev [ started ]
Runlevel: boot
hwclock [ started ]
modules [ started ]
device-mapper [ started ]
fsck [ started ]
root [ started ]
mtab [ started ]
localmount [ started ]
sysctl [ started ]
bootmisc [ started ]
termencoding [ started ]
keymaps [ started ]
swapfiles [ started ]
ufw [ started ]
procfs [ started ]
dbus [ started ]
tmpfiles.setup [ started ]
serial [ started ]
hostname [ started ]
consolekit [ started ]
consolefont [ started ]
xdm [ started ]
loopback [ started ]
Runlevel: single
Runlevel: default
swap [ started ]
bluetooth [ started ]
syslog-ng [ started ]
sshd [ started ]
fbcondecor [ started ]
atd [ started ]
NetworkManager [ started ]
avahi-daemon [ started ]
cupsd [ started ]
mdadm [ started ]
acpid [ started ]
nfsclient [ started ]
netmount [ started ]
alsasound [ started ]
laptop_mode [ started ]
cups-browsed [ started ]
hddtemp [ started ]
mysql [ started ]
nfs [ started ]
samba [ started ]
urandom [ started ]
vixie-cron [ started ]
local [ started ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
rpcbind [ started ]
rpc.statd [ started ]
rpc.pipefs [ started ]
rpc.idmapd [ started ]
xdm-setup [ started ]
Dynamic Runlevel: manual
meshedgedx fitzcarraldo #
The allocations of services to runlevels are shown below:
meshedgedx fitzcarraldo # rc-update show -v
NetworkManager | default
NetworkManagerDispatcher |
acpid | default
alsasound | default
apache2 |
atd | default
atieventsd |
avahi-daemon | default
avahi-dnsconfd |
bluetooth | default
bootmisc | boot
brltty |
busybox-ntpd |
busybox-watchdog |
cgconfig |
cgred |
cgroups |
clamd |
consolefont | boot
consolekit | boot
courier-authlib |
cpupower |
cups-browsed | default
cupsd | default
dbus | boot
deluged |
devfs | sysinit
device-mapper | boot
dgc |
dhcpcd |
dmcrypt |
dmesg | sysinit
dmeventd |
dropbox |
eposd |
fancontrol |
fbcondecor | default
fsck | boot
fuse |
git-daemon |
gkrellmd |
gpm |
gpsd |
hddtemp | default
hdparm |
heimdal-kadmind |
heimdal-kcm |
heimdal-kdc |
heimdal-kpasswdd |
hostname | boot
hsqldb |
hwclock | boot
ip6tables |
iptables |
irexec |
keymaps | boot
killprocs | shutdown
kmod-static-nodes |
laptop_mode | default
lircd |
lircmd |
lm_sensors |
local | default
localmount | boot
loopback | boot
lvm |
lvm-monitoring |
lvmetad |
mdadm | default
mdraid |
microcode_ctl |
modules | boot
mount-ro | shutdown
mtab | boot
multipath |
multipathd |
mysql | default
nas |
net.aol |
net.ath0 |
net.ath1 |
net.ath2 |
net.ath3 |
net.ath4 |
net.eth0 |
net.eth1 |
net.eth2 |
net.eth3 |
net.eth4 |
net.eth5 |
net.eth6 |
net.eth7 |
net.eth8 |
net.lo |
net.ppp0 |
net.ppp1 |
net.ppp2 |
net.ppp3 |
net.ra0 |
net.ra1 |
net.ra2 |
net.ra3 |
net.ra4 |
net.ra5 |
net.wlan0 |
net.wlan1 |
net.wlan2 |
net.wlan3 |
netmount | default
nfs | default
nfsclient | default
nfsmount |
ntp-client |
ntp-client.bak.20141013 |
ntpd |
numlock |
pciparm |
pktcdvd |
polipo |
procfs | boot
pwcheck |
pydoc-2.7 |
pydoc-3.2 |
pydoc-3.3 |
pydoc-3.4 |
rename_ethX |
rfcomm |
root | boot
rpc.idmapd |
rpc.pipefs |
rpc.statd |
rpcbind |
rrdcached |
rsyncd |
samba | default
saned |
saslauthd |
savecache | shutdown
serial | boot
slpd |
smartd |
snmpd |
snmptrapd |
sntp |
sshd | default
svnserve |
swap | default
swapfiles | boot
swclock |
sysctl | boot
sysfs | sysinit
syslog-ng | default
system-tools-backends |
termencoding | boot
timidity |
tmpfiles.dev | sysinit
tmpfiles.setup | boot
tor |
twistd |
udev | sysinit
ufw | boot
urandom | default
vboxwebsrv |
vixie-cron | default
vpnc |
wpa_supplicant |
xdm | boot
xdm-setup |
xinetd |
meshedgedx fitzcarraldo #
My installation has the following six runlevels:
meshedgedx fitzcarraldo # ls /etc/runlevels
boot default nonetwork shutdown single sysinit
About Fitzcarraldo
Fitzcarraldo's Blog 
Pingback: NetworkManager creating a new connection ‘eth0′ that does not work, Part 3 | Fitzcarraldo's Blog
Pingback: NetworkManager creates a new connection ‘eth0’ that does not work | Fitzcarraldo's Blog
Thanks Fitzcarraldo; although there’s no solution … yet, your post, supported by obvious thorough investigation, has saved me a lot of time by obviating the need to do similar experiments myself! 🙂 Your effort is appreciated!
You’re welcome. I’m currently using NetworkManager 1.0.12-r1 on my Clevo W230SS laptop running Gentoo Stable Branch, and NetworkManager 1.2.2 on my Compal NBLB2 laptop running Gentoo Testing Branch, and the problem of the additional ‘eth0’ connection does not exist any more on either laptop, so the NetworkManager developers must have fixed the problem.
I’ve found that checking ‘Automatically connect to this network when it is available’ in the General tab for a single, working ‘eth0’ seems to keep the additional, non-working ‘eth0’ from being created.
Hey Fitzcarraldo,
Thanks for the detailed notes on this problemo!
I found the only way to fix this was to run a three line script at boot up
to bring down eth0, restart network-manager, bring up eth0
#!/bin/bash
# script to remove incorrect “eth0”
# to allow network-manager to correctly allocate address to interface
/sbin/ifconfig eth0 down
/usr/sbin/service network-manager restart
/sbin/ifconfig eth0 up
call it “eth-fix.sh” and save it it /usr/local/bin/eth-fix.sh
add a line to root crontab to run the script at boot:
@reboot /usr/local/bin/eth-fix.sh
reboot and the non-working “eth0” is removed and correct “eth0” is brought up!
You’re welcome. I’m currently using NetworkManager 1.18.4 on my Clevo W230SS laptop running Gentoo Stable Branch, and NetworkManager 1.18.6 on my Compal NBLB2 laptop running Gentoo Testing Branch, and the problem of the additional ‘eth0’ connection has not existed on either laptop for several years. It’s odd that you are still experiencing the problem. Anyway, it’s good to read that you have found a way to remove the non-working ‘eth0’ connection.