A method of ‘masking’ an OpenRC service (NetworkManager, in this case)

A Gentoo Linux user with an installation using OpenRC recently asked in the Gentoo Forums how to either a) disable NetworkManager so that it would not interfere with his netifrc configuration to give his installation a static IP address, or b) configure NetworkManager to use a static IP address (see the thread NetworkManager and static IP [SOLVED! THANKYOU]). In the end he solved the problem by uninstalling NetworkManager, the cleanest solution in his case given that his desktop machine is always in the same location and he does not need the features NetworkManager provides.

Now, although I use NetworkManager instead of netifrc, what intrigued me is that disabling the NetworkManager service using the standard command below does not stop the NetworkManager init script from running at boot-up:

root # rc-update delete NetworkManager default

Despite using the above command, following a reboot the NetworkManager service is still started and becomes active, and the NetworkManager daemon is running. Web browsers and other applications requiring network access still work. In order to stop the service running immediately so that his netifrc static IP address configuration could work, the aforementioned Gentoo user had to stop the NetworkManager service as follows:

root # /etc/init.d/NetworkManager stop

(The command ‘rc-service NetworkManager stop‘ does the same thing.)

The behaviour is the same on my laptop running Gentoo with OpenRC 0.22.4 and NetworkManager installed by networkmanager-1.4.0-r1 ebuild (with the upstream patch and necessary edit to the init script mentioned in Gentoo Bug Report No. 595806 – net-misc/networkmanager-1.4.0-r1[consolekit]: doesn’t automatically activate connections marked with "Automatically connect to this network when it’s available").

So two questions arose: What launches the NetworkManager init script when it has not been added to a runlevel? What needs to be done to stop this from happening? My curiosity was piqued.

As it happens, a somewhat similar situation exists when using systemd rather than OpenRC, as explained in Arch Linux Forums thread [SOLVED] NetworkManager auto restart even though I stop it. and Red Hat Bugzilla Report No. 815243 – Even though NetworkManager was manually stopped, it gets restarted automatically via D-Bus, although those were primarily concerned with how to prevent NetworkManager being restarted during the same session, i.e. without having rebooted.

The following systemd commands are needed to stop immediately the NetworkManager service and keep it from being restarted subsequently during the current session and after rebooting:

root # systemctl mask NetworkManager
root # systemctl stop NetworkManager
root # systemctl disable NetworkManager

Unfortunately there is no equivalent mask command for an OpenRC service. The equivalent OpenRC commands for the second and third commands above are:

root # rc-service NetworkManager stop
root # rc-update delete NetworkManager default

However, as I pointed out earlier, for some reason the latter command does not stop OpenRC running the NetworkManager init script at boot.

I wondered how I could ‘mask’ the NetworkManager service in OpenRC. I asked myself what the systemd mask command actually does. Well, it simply creates a symlink from /etc/systemd/system/NetworkManager.service to /dev/null so that there is no longer a real unit file for systemd to use, and therefore systemd can no longer launch the service. So why not do something similar in OpenRC. I hit upon the idea of telling the NetworkManager init script it needs a non-existent service in order to start, thus preventing OpenRC from starting the NetworkManager service:

root # echo 'rc_need="non-existent_service"' >> /etc/conf.d/NetworkManager # (Or just edit the file manually.)

That is all there is to it. When booting, OpenRC now displays the messages shown below:

* ERROR: NetworkManager needs service(s) non-existent_service
* ERROR: cannot start netmount as NetworkManager would not start
* ERROR: cannot start samba as NetworkManager would not start

As shown below, now the service is not started, so the NetworkManager daemon is never launched:

root # rc-status
Runlevel: default
 dbus                                                  [  started  ]
 syslog-ng                                             [  started  ]
 consolekit                                            [  started  ]
 netmount                                              [  stopped  ]
 cupsd                                                 [  started  ]
 samba                                                 [  stopped  ]
 cronie                                                [  started  ]
 clamd                                                 [  started  ]
 bluetooth                                             [  started  ]
 xdm                                                   [  started  ]
 cups-browsed                                          [  started  ]
 sshd                                                  [  started  ]
 local                                                 [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
 modules-load                                          [  started  ]
 xdm-setup                                             [  started  ]
 avahi-daemon                                          [  started  ]
Dynamic Runlevel: manual
root # ps -ef | grep -v grep | grep -i network
root #

As expected, given that the netmount service and samba service depend on the NetworkManager service starting, neither of those services were able to start either.

Furthermore, because I masked the service, if I attempt to start it manually:

root # rc-service NetworkManager restart
 * ERROR: NetworkManager needs service(s) non-existent_service

To unmask the service in OpenRC, all that is needed is:

root # sed -i '/rc_need="non-existent_service"/d' /etc/conf.d/NetworkManager # (Or just edit the file manually.)

Note that, instead of “non-existent_service” I could have written “fubar”, “null” or any other string that is not the name of an actual service. But “non-existent_service” is more meaningful and less likely to confuse me when viewing system messages and contents of the service configuration file.

In summary…

Why does OpenRC run the NetworkManager service init script when it is not in any runlevel?

I have no idea!

I wondered if the D-Bus service does it. The Arch Wiki article on NetworkManager claims this is the case (see the section titled Disable NetworkManager). However, my attempts at preventing D-Bus doing anything to NetworkManager did not stop the NetworkManager init script from being run at boot. I deleted /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf and /etc/dbus-1/system.d/nm-dispatcher.conf but that did not help. Neither did creating an appropriate /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf or /etc/dbus-1/system-local.conf. There is no /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service file in my Gentoo installation using OpenRC, but creating one did not help either. So, if you know what runs the OpenRC NetworkManager init script when it is not in any runlevel, please post a comment.

Anyway, I now know how to prevent it happening, so I have satisfied my curiosity. Below I list the commands I actually used in a Gentoo Linux installation (amd64, OpenRC) and a Sabayon Linux installation (~amd64, systemd) to check the functionality.

OpenRC

The following two (optionally three) commands are needed to stop immediately the NetworkManager service and prevent it being restarted subsequently during this session and after rebooting:

root # rc-service NetworkManager stop
root # echo 'rc_need="non-existent_service"' >> /etc/conf.d/NetworkManager
root # rc-update del NetworkManager default # (Optional.)

The following two (optionally three) commands are needed to unmask the NetworkManager service and start it immediately, and make it start automatically after rebooting:

root # sed -i '/rc_need="non-existent_service"/d' /etc/conf.d/NetworkManager
root # rc-service NetworkManager restart
root # rc-update add NetworkManager default # Only needed if I earlier deleted the service from the default runlevel.

systemd

The following three commands are needed to stop immediately the NetworkManager service and prevent it being restarted subsequently during this session and after rebooting:

root # systemctl mask NetworkManager
root # systemctl stop NetworkManager
root # systemctl disable NetworkManager

The following three systemd commands are needed to unmask the NetworkManager service and start it immediately, and also make it start automatically after rebooting:

root # systemctl unmask NetworkManager
root # systemctl enable NetworkManager
root # systemctl start NetworkManager
Advertisements

NetworkManager: Failed to activate – The name org.freedesktop.NetworkManager was not provided by any .service files

Because I need to connect quickly and easily to numerous wired and wireless networks (DHCP or static IP addressing), I use NetworkManager in my Gentoo Linux amd64 installation running OpenRC and KDE 4. My Clevo W230SS laptop has an Intel Dual Band Wireless-AC 7260 Plus Bluetooth adapter card, and my installation uses the iwlwifi module:

# lspci -knn | grep Net -A2
03:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev bb)
        Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4070]
        Kernel driver in use: iwlwifi
# lsmod | grep iwl
iwlmvm                143919  0
iwlwifi                75747  1 iwlmvm

As I am using NetworkManager instead of netifrc, in accordance with the instructions in the Gentoo Wiki article on NetworkManager I do not have any net.* services enabled (not even net.lo):

# rc-update show -v
       NetworkManager |      default                 
                acpid |                              
            alsasound |                              
         avahi-daemon |                              
       avahi-dnsconfd |                              
               binfmt | boot                         
            bluetooth |      default                 
             bootmisc | boot                         
         busybox-ntpd |                              
     busybox-watchdog |                              
                clamd |                              
          consolefont |                              
           consolekit |      default                 
               cronie |      default                 
         cups-browsed |      default                 
                cupsd |      default                 
                 dbus |      default                 
                devfs |                       sysinit
               dhcpcd |                              
                dhcpd |                              
             dhcrelay |                              
            dhcrelay6 |                              
                dmesg |                       sysinit
              dropbox |                              
           fancontrol |                              
                 fsck | boot                         
                 fuse |                              
           git-daemon |                              
                  gpm |                              
              hddtemp |                              
             hostname | boot                         
              hwclock | boot                         
            ip6tables |                              
             iptables |                              
              keymaps | boot                         
            killprocs |              shutdown        
    kmod-static-nodes |                       sysinit
           lm_sensors |                              
                local |      default                 
           localmount | boot                         
             loopback | boot                         
      mit-krb5kadmind |                              
          mit-krb5kdc |                              
       mit-krb5kpropd |                              
              modules | boot                         
             mount-ro |              shutdown        
                 mtab | boot                         
                mysql |                              
                  nas |                              
         net.enp4s0f1 |                              
               net.lo |                              
             netmount |      default                 
           ntp-client |                              
                 ntpd |                              
           nullmailer |                              
              numlock |                              
  nvidia-persistenced |                              
           nvidia-smi |                              
              osclock |                              
              pciparm |                              
               procfs | boot                         
              pwcheck |                              
            pydoc-2.7 |                              
            pydoc-3.4 |                              
               rfcomm |                              
                 root | boot                         
               rsyncd |                              
            s6-svscan |                              
                samba |      default                 
                saned |                              
            saslauthd |                              
            savecache |              shutdown        
                 sntp |                              
                 sshd |      default                 
             svnserve |                              
                 swap | boot                         
            swapfiles | boot                         
              swclock |                              
               sysctl | boot                         
                sysfs |                       sysinit
            syslog-ng |      default                 
        teamviewerd10 |                              
         termencoding | boot                         
             timidity |                              
         tmpfiles.dev |                       sysinit
       tmpfiles.setup | boot                         
               twistd |                              
                 udev |                       sysinit
                  ufw | boot                         
              urandom | boot                         
       wpa_supplicant |                              
                  xdm |      default                 
            xdm-setup |

I have left the netmount service enabled in case I want to use network-attached file shares at home or in one of the various office locations where I work.

Networking works fine on my laptop with the many wired and wireless networks I have used except for one particular public wireless network (it is in an airport, has multiple Access Points, and its Access Points only support 802.11a/b/g, which may or may not be relevant) for which the following message would usually appear in a pop-up window when I tried to connect to the network from the KDE network management GUI after start-up:

Failed to activate
The name org.freedesktop.NetworkManager was not provided by any .service files

Error message displayed by KDE when trying to connect to one specific network

Error message displayed by KDE when trying to connect to one specific network


This occurred with both networkmanager-1.0.2-r1 and networkmanager-1.0.6, the two Stable Branch releases of NetworkManager currently available in Gentoo Linux.

The wireless network is not the only network at that particular location, and the ‘Failed to activate’ message occurred whichever network (wireless or wired) I tried to access at that location. When this problem occurred, it transpired that the NetworkManager service was not running (it had crashed):

$ nmcli d
Error: NetworkManager is not running.
$ rc-status
Runlevel: default
 dbus                   [  started  ]
 NetworkManager         [  crashed  ]
 netmount               [  started  ]
 syslog-ng              [  started  ]
 cupsd                  [  started  ]
 samba                  [  crashed  ]
 consolekit             [  started  ]
 cronie                 [  started  ]
 bluetooth              [  started  ]
 xdm                    [  started  ]
 cups-browsed           [  started  ]
 sshd                   [  started  ]
 local                  [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 xdm-setup              [  started  ]
 avahi-daemon           [  started  ]
Dynamic Runlevel: manual

(I am not bothered that Samba crashes in that particular location. It crashes even if a connection is established, because the public wireless network does not provide network file systems. Samba works fine when I connect the laptop to an office network or to my home network.)

Even if the ‘Failed to activate’ message occurred, sometimes (but not always) the laptop could still connect to networks after I restarted the NetworkManager service (albeit sometimes it was necessary to restart it more than once):

# /etc/init.d/NetworkManager restart

When it is possible to connect to networks, the NetworkManager service is of course running:

$ nmcli d
DEVICE    TYPE      STATE        CONNECTION           
sit0      sit       connected    sit0                 
wlp3s0    wifi      connected    Free_Airport_Internet
enp4s0f1  ethernet  unavailable  --                   
lo        loopback  unmanaged    --        
$ rc-status
Runlevel: default
 dbus                   [  started  ]
 NetworkManager         [  started  ]
 netmount               [  started  ]
 syslog-ng              [  started  ]
 cupsd                  [  started  ]
 samba                  [  crashed  ]
 consolekit             [  started  ]
 cronie                 [  started  ]
 bluetooth              [  started  ]
 xdm                    [  started  ]
 cups-browsed           [  started  ]
 sshd                   [  started  ]
 local                  [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 xdm-setup              [  started  ]
 avahi-daemon           [  started  ]
Dynamic Runlevel: manual

I searched the Web for the error message and, based on a recommendation on the Web page ‘nm-applet gives errors‘ claiming the problem is due to the iwlwifi driver when used with an Intel 7260 controller, I created a file /etc/modprobe.d/iwlwifi.conf containing the following line, and rebooted:

options iwlwifi power_save=0

However, the error message still occurred. So I changed the iwlwifi module options line to the following, as also recommended on that page, and rebooted:

options iwlwifi 11n_disable=1 power_save=0

However, the error message still occurred.

The default value for OpenRC’s rc_depend_strict variable is YES if rc_depend_strict is not declared in the file /etc/rc.conf, but I do not think that is the cause of the problem:

# Do we allow any started service in the runlevel to satisfy the dependency
# or do we want all of them regardless of state? For example, if net.eth0
# and net.eth1 are in the default runlevel then with rc_depend_strict="NO"
# both will be started, but services that depend on 'net' will work if either
# one comes up. With rc_depend_strict="YES" we would require them both to
# come up.
#rc_depend_strict="YES"

As already mentioned, sometimes just restarting the NetworkManager service once or more did enable the laptop to connect to the network. This made me wonder whether the problem had something to do either with the timing of the launch of the NetworkManager service or with the timing of the service establishing a connection. As netmount is the only other network-related service enabled at start-up, I checked the netmount service’s configuration file /etc/conf.d/netmount to see what it contained (it’s the same in both the latest stable openrc-0.17 and the latest testing openrc-0.18.2):

# You will need to set the dependencies in the netmount script to match
# the network configuration tools you are using. This should be done in
# this file by following the examples below, and not by changing the
# service script itself.
#
# Each of these examples is meant to be used separately. So, for
# example, do not set rc_need to something like "net.eth0 dhcpcd".
#
# If you are using newnet and configuring your interfaces with static
# addresses with the network script, you  should use this setting.
#
#rc_need="network"
#
# If you are using oldnet, you must list the specific net.* services you
# need.
#
# This example assumes all of your netmounts can be reached on
# eth0.
#
#rc_need="net.eth0"
#
# This example assumes some of your netmounts are on eth1 and some
# are on eth2.
#
#rc_need="net.eth1 net.eth2"
#
# If you are using a dynamic network management tool like
# networkmanager, dhcpcd in standalone mode, wicd, badvpn-ncd, etc, to
# manage the network interfaces with the routes to your netmounts, you
# should list that tool.
#
#rc_need="networkmanager"
#rc_need="dhcpcd"
#rc_need="wicd"
#
# The default setting is designed to be backward compatible with our
# current setup, but you are highly discouraged from using this. In
# other words, please change it to be more suited to your system.
#
rc_need="net"

As I am using NetworkManager rather than netifrc, I followed the instructions in the file’s comments and changed the file’s contents from:

rc_need="net"

to:

rc_need="networkmanager"

After making the above change, the console messages at boot-up included a new message:

* ERROR: netmount needs service(s) networkmanager

That message made sense: rc_need had been set to "networkmanager" and, obviously, netmount can only do its job if NetworkManager is running (AND a network connection has been established). However, notice that the name of the NetworkManager service initscript is /etc/init.d/NetworkManager, not /etc/init.d/networkmanager. In other words, the instructions in /etc/conf.d/netmount are wrong: the name of the service is actually ‘NetworkManager‘, not ‘networkmanager‘. So I changed /etc/conf.d/netmount to contain rc_need="NetworkManager" instead of rc_need="networkmanager" and, unsurprisingly, the above-mentioned error message no longer occurs. I have filed Gentoo Bugzilla Bug Report No. 564846 requesting that the comment in the configuration file be changed.

Nevertheless, the ‘Failed to activate’ message still occurred when I tried to connect to any network at that location by using the DE’s network management GUI, and therefore I still needed to restart the NetworkManager service manually in order to be able to connect to any network there. Although I am not yet sure of the root cause and solution, I have found a work-around which avoids me having to manually restart the NetworkManager service, as explained below.

Although OpenRC correctly launches the NetworkManager service, that service remains inactive until it actually establishes a network connection. This is not a bug, it is the way OpenRC and NetworkManager work (see the explanation in the Gentoo Forums thread NetworkManager has started, but is inactive). This is why the following console message appears during boot-up:

* WARNING: NetworkManager has already started, but is inactive

If you did not configure NetworkManager to connect automatically to a network, after logging-in to the DE you will need to use the DE’s network management GUI (plasma-nm in the case if KDE, nm-applet in the case of e.g. Xfce) to tell NetworkManager to connect to the desired network. However, I found that waiting that long before trying to connect is too late to avoid the ‘Failed to activate’ problem, i.e. NetworkManager crashes after a while. I do not know why this happens, but it usually happens only when I am at the location covered by one specific wireless network (which is why I wonder if the problem is a result of that network only supporting 802.11a/b/g). By configuring NetworkManager to connect automatically to the wireless network which seemed to trigger the problem, the NetworkManager service tries to connect earlier. It is possible to configure NetworkManager to do this either by using the DE network GUI and ticking ‘Automatically connect to this network when it is available’ for the relevant network connection, or by directly editing the relevant connection’s file in the directory /etc/NetworkManager/system-connections/.

Of the various wired and wireless connections I had configured on the laptop, I had named the problematic wireless network’s connection ‘Free_Airport_Internet’. So I edited the file /etc/NetworkManager/system-connections/Free_Airport_Internet and deleted the line ‘autoconnect=false‘ in the [connections] section of the file (the default value of the autoconnect variable is TRUE – see man nm-settings). I could instead have done this by using the DE’s network manager GUI and ticking ‘Automatically connect to this network when it is available’ for that network connection. Now, when the laptop boots, NetworkManager tries to connect to that network and the ‘Failed to activate’ problem is avoided. This works with or without the iwlwifi driver options I mentioned above, so, despite the claim on the Web page I referenced above, the root cause of the problem does not appear to be the iwlwifi driver. What I don’t understand is why the problem only seems to occur with one particular network (a public wireless network which happens to only support 802.11a/b/g), i.e. even if none of the NetworkManager connection files in my installation have been configured to try to establish a connection automatically, with all the other wireless networks I have used in other locations (I believe those all support at least 802.11a/b/g/n) I have been able to establish a connection manually by using the DE’s network management GUI.

The bottom line

If your installation uses NetworkManager and you experience the ‘Failed to activate’ message when trying to connect to networks from the DE’s network management GUI, check if the NetworkManager service is running. You can check by using the command ‘nmcli d‘ in a console. If it is not running, try to restart the NetworkManager service from the command line. If the connection is not already configured to start automatically, configure it to start automatically in order to try to make NetworkManager become active at an early stage.

POSTSCRIPT (November 6, 2015)

The two links below are to old bug reports regarding earlier versions of NetworkManager having trouble using wireless networks with multiple Access Points. I wonder if the problem I saw with NetworkManager crashing when not configured to connect automatically to the specific network I mentioned above is somehow related to those problems:

background scanning causes drivers to disassociate – WiFi roaming causes NetworkManager to lose routing

network-manager roams to (none) ((none)) – background scanning

Roaming to BSSID “(none)” certainly happens with this particular network too, as shown by the messages in the laptop’s system log from yesterday when I was using the laptop with that network (the laptop was stationary the whole time):

# cat /var/log/messages | grep "Nov  5 11" | grep NetworkManager | grep \(none\)
Nov  5 11:01:22 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID 04:C5:A4:C3:F9:EE (Free_Airport_Internet) to (none) ((none))
Nov  5 11:01:22 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)
Nov  5 11:13:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID B8:BE:BF:69:89:6E (Free_Airport_Internet) to (none) ((none))
Nov  5 11:13:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to 04:C5:A4:C3:F9:EE (Free_Airport_Internet)
Nov  5 11:15:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID 04:C5:A4:C3:F9:EE (Free_Airport_Internet) to (none) ((none))
Nov  5 11:15:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)
Nov  5 11:19:22 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID B8:BE:BF:69:89:6E (Free_Airport_Internet) to (none) ((none))
Nov  5 11:19:23 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)
Nov  5 11:49:50 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID B8:BE:BF:69:89:6E (Free_Airport_Internet) to (none) ((none))
Nov  5 11:49:50 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to 68:BC:0C:A1:3C:DE (Free_Airport_Internet)
Nov  5 11:51:51 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID 68:BC:0C:A1:3C:DE (Free_Airport_Internet) to (none) ((none))
Nov  5 11:51:51 clevow230ss NetworkManager[2459]:   (wlp3s0): roamed from BSSID (none) ((none)) to B8:BE:BF:69:89:6E (Free_Airport_Internet)

Today I’m using a hotel network in my hotel room, and that does not roam to BSSID “(none)”, but I don’t know if my room is within range of more than one Access Point:

# cat /var/log/messages | grep "Nov  6" | grep NetworkManager | grep \(none\)
#

Anyway, with the work-around described in this post I have not had any further trouble accessing the particular network, but it would be interesting to know the root cause.

NetworkManager creating a new connection ‘eth0’ that does not work, Part 4

Further to my previous post, this is to report the result of another experiment. By doing all the following I can stop NetworkManager creating an invalid second eth0 connection:

  • Enable IPv6 system-wide in /etc/modprobe.d/aliases.conf by commenting-out ‘alias net-pf-10 off‘.
  • Disable use of IPv6 by the Avahi daemon in /etc/avahi/avahi-daemon.conf (see the four additional lines given in my previous post).
  • Use plasma-nm to edit the connection profile for ‘eth0’ that I had already created. Click on the IPv6 tab and ensure ‘Method: Ignored‘ is selected. Click on the IPv4 tab and ensure ‘Method: Automatic‘ is selected and ‘IPv4 is required for this connection‘ is ticked. Ticking ‘IPv4 is required for this connection‘ adds the line ‘may-fail=false‘ in the [ipv4] section in the file /etc/NetworkManager/system-connections/eth0 (the default value for may-fail is ‘true‘ if the box has not been ticked and may-fail has not been assigned in the file).

The various experiments I have conducted are summarised in the following table:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true true false false false
Invalid second eth0 created usually no usually no yes yes

As disabling IPv6 system-wide makes it impossible for NetworkManager to use IPv6, the above table can actually be written as follows:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes||no no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true||false true false false false
Invalid second eth0 created usually no usually no yes yes

I still think there is a bug in NetworkManager. I would not have expected NetworkManager to create a second eth0 connection and make it an IPv6 Link-Local connection when all the following are true:

  • /etc/NetworkManager.conf has ‘no-auto-default=eth0‘ in the [main] section.
  • IPv4 is required for this connection‘ is not ticked in plasma-nm (i.e. the [ipv4] section in /etc/NetworkManager/system-connections/eth0 contains either the line ‘may-fail=true‘ or the line ‘may-fail=‘).
  • Method: Automatic‘ is selected for IPv4 (‘method=auto‘ under [ipv4] in /etc/NetworkManager/system-connections/eth0).
  • Method: Ignored‘ is selected for IPv6 (‘method=ignore‘ under [ipv6] in /etc/NetworkManager/system-connections/eth0) and the other fields on the IPv6 tab have been rendered unselectable as a result.

Anyway, I will keep IPv6 disabled in /etc/avahi/avahi-daemon.conf and IPv6 enabled system-wide. This seems to be the first thing to try if you’re experiencing the creation of an invalid additional eth0 connection with an IPv6 Link-Local address and you’re sure that none of the net.* services are running.

NetworkManager creating a new connection ‘eth0′ that does not work, Part 3

I’m even more convinced the problem discussed in my previous post is due to a bug in NetworkManager. I believe the issue with the Avahi daemon generating an IPv6 Link-Local address is a consequence of NetworkManager not always activating an interface and therefore not obtaining an IPv4 address, i.e. the IPv6 Link-Local address produced by the Avahi daemon is a side effect, not the root cause.

After my previous post I discovered that adding ‘use-ipv6=no‘ in /etc/avahi/avahi-daemon.conf (my Experiment 2) had not prevented avahi-daemon using IPv6. However, adding the following lines in /etc/avahi/avahi-daemon.conf defintely does prevent avahi-daemon from using IPv6 in my installation:

use-ipv4=yes
use-ipv6=no
publish-a-on-ipv6=no
publish-aaaa-on-ipv4=no

You can see in the message log below that the Avahi daemon is no longer generating an IPv6 Link-Local address. However, even with IPv6 disabled in avahi-daemon, an invalid second eth0 connection with an IPv6 Link-Local address still occurs in my installation. This indicates the problem is not caused by the Avahi daemon.

Mar 18 22:17:31 localhost syslog-ng[8316]: syslog-ng starting up; version='3.6.2'
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  NetworkManager (version 1.0.0) is starting...
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  Read config: /etc/NetworkManager/NetworkManager.conf
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  WEXT support is enabled
Mar 18 22:17:34 localhost kernel: fglrx_pci 0000:01:00.0: irq 34 for MSI/MSI-X
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8351
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8352
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8353
Mar 18 22:17:34 localhost kernel: <6>[fglrx] IRQ 34 Enabled
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Shared offset:0, size:1000000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e2000, size:4000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e6000, size:51a000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:3fff3000, size:d000 
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/Cisco00497
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/eth0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/DIRECT-HeC460 Series
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  monitoring kernel firmware directory '/lib/firmware'.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi hardware radio set enabled
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN hardware radio set enabled
Mar 18 22:17:33 localhost /etc/init.d/NetworkManager[8326]: WARNING: NetworkManager has started, but is inactive
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wwan.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi disabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiMAX enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Networking is enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): new Generic device (driver: 'unknown' ifindex: 1)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): exported as /org/freedesktop/NetworkManager/Devices/0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): new Ethernet device (driver: 'atl1c' ifindex: 2)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  startup complete
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: starting connection 'eth0'
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): using nl80211 for WiFi device control
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 3)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): exported as /org/freedesktop/NetworkManager/Devices/2
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): preparing device
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) starting...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) successful.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) scheduled.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
Mar 18 22:17:33 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ModemManager1' (using servicehelper)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  NetworkManager state is now CONNECTED_LOCAL
Mar 18 22:17:33 localhost acpid[8386]: starting up with netlink and the input layer
Mar 18 22:17:33 localhost acpid[8386]: 6 rules loaded
Mar 18 22:17:33 localhost acpid[8386]: waiting for events: event logging is off
Mar 18 22:17:34 localhost ModemManager[8385]: <info>  ModemManager (version 1.4.2) starting in system bus...
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  (eth0): Activation: successful, device activated.
Mar 18 22:17:34 localhost dbus[7763]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 18 22:17:34 localhost nm-dispatcher[8435]: Dispatching action 'up' for eth0
Mar 18 22:17:34 localhost rpc.statd[8451]: Version 1.3.2 starting
Mar 18 22:17:34 localhost rpc.statd[8451]: Flags: TI-RPC 
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8457]: status: inactive
Mar 18 22:17:34 localhost rpc.statd[8451]: Running as root.  chown /var/lib/nfs to choose different user
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8469]: status: inactive
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ModemManager1'
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager disappeared from bus
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager available in the bus
Mar 18 22:17:35 localhost sm-notify[8556]: Version 1.3.2 starting
Mar 18 22:17:35 localhost avahi-daemon[8585]: Found user 'avahi' (UID 108) and group 'avahi' (GID 444).
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped root privileges.
Mar 18 22:17:35 localhost avahi-daemon[8585]: avahi-daemon 0.6.31 starting up.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully called chroot().
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped remaining capabilities.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/sftp-ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Network interface enumeration completed.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Registering HINFO record with values 'X86_64'/'LINUX'.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Server startup complete. Host name is meshedgedx.local. Local service cookie is 3778762828.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/ssh.service) successfully established.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/sftp-ssh.service) successfully established.
Mar 18 22:17:35 localhost ntpd[8645]: ntpd 4.2.8@1.3265-o Wed  4 Mar 02:23:30 UTC 2015 (1): Starting
Mar 18 22:17:35 localhost ntpd[8645]: Command line: ntpd -g -q
Mar 18 22:17:35 localhost ntpd[8645]: proto: precision = 0.061 usec (-24)
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 0 v6wildcard [::]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 2 lo 127.0.0.1:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 3 lo [::1]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 4 eth0 [fe80::725a:b6ff:fe3e:c18a%2]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listening on routing socket on fd #21 for interface updates
Mar 18 22:17:36 localhost kernel: fbcondecor: console 1 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 1
Mar 18 22:17:37 localhost kernel: fbcondecor: console 2 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 2
Mar 18 22:17:37 localhost kernel: fbcondecor: console 3 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 3
Mar 18 22:17:37 localhost kernel: fbcondecor: console 4 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 4
Mar 18 22:17:37 localhost kernel: fbcondecor: console 5 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 5
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth daemon 5.28
Mar 18 22:17:36 localhost bluetoothd[8787]: Starting SDP server
Mar 18 22:17:37 localhost kernel: Bluetooth: Core ver 2.19
Mar 18 22:17:37 localhost kernel: NET: Registered protocol family 31
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI device and connection manager initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: L2CAP socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: SCO socket layer initialized
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP filters: protocol multicast
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP socket layer initialized
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth management interface 1.7 initialized
Mar 18 22:17:36 localhost NetworkManager[8346]: <info>  use BlueZ version 5
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0': not supported by any plugin
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
Mar 18 22:17:39 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper)
Mar 18 22:17:39 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ColorManager'
Mar 18 22:17:41 localhost kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost laptop-mode[8947]: Laptop mode 
Mar 18 22:17:43 localhost laptop-mode[8948]: enabled, not active
Mar 18 22:17:58 localhost kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Mar 18 22:17:58 localhost rpc.mountd[9741]: Version 1.3.2 starting
Mar 18 22:17:59 localhost kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Mar 18 22:17:59 localhost kernel: NFSD: starting 90-second grace period (net ffffffff81c3d580)
Mar 18 22:17:58 localhost sm-notify[9760]: Version 1.3.2 starting
Mar 18 22:17:58 localhost sm-notify[9760]: Already notifying clients; Exiting!
Mar 18 22:18:00 localhost sshd[9816]: Server listening on 0.0.0.0 port 22.
Mar 18 22:18:00 localhost sshd[9816]: Server listening on :: port 22.
Mar 18 22:18:00 localhost cron[9870]: (CRON) STARTUP (V5.0)
Mar 18 22:18:00 localhost su[9899]: Successful su for fitzcarraldo by root
Mar 18 22:18:00 localhost su[9899]: + /dev/console root:fitzcarraldo
Mar 18 22:18:00 localhost su[9899]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost dbus[7763]: [system] Activating service name='org.freedesktop.RealtimeKit1' (using servicehelper)
Mar 18 22:18:01 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully called chroot.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully dropped privileges.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully limited resources.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Watchdog thread running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Canary thread running.
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_unix(kde:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_ck_connector(kde:session): nox11 mode, ignoring PAM_TTY :0
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] sink.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] source.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module-jackdbus-detect.c: Unable to contact D-Bus session bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module.c: Failed to load module "module-jackdbus-detect" (argument: "channels=2"): initialization failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Module load failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost su[9899]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9964]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9966]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9968]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:15 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)
Mar 18 22:18:15 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UPower'
Mar 18 22:18:17 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper)
Mar 18 22:18:17 localhost udisksd[10120]: udisks daemon version 2.1.4 starting
Mar 18 22:18:17 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UDisks2'
Mar 18 22:18:17 localhost udisksd[10120]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Mar 18 22:18:19 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:16:fa:25:28:01:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=0 PROTO=2 
Mar 18 22:18:54 localhost hp-systray[10453]: hp-systray[10453]: error: option -s not recognized
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Successfully made thread 10469 of process 10469 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:55 localhost pulseaudio[10469]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Successfully made thread 10485 of process 10485 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:56 localhost pulseaudio[10485]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:19:04 localhost polkitd[7911]: Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.52 [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Mar 18 22:19:10 localhost su[10569]: Successful su for root by fitzcarraldo
Mar 18 22:19:10 localhost su[10569]: + /dev/pts/0 fitzcarraldo:root
Mar 18 22:19:10 localhost su[10569]: pam_unix(su:session): session opened for user root by fitzcarraldo(uid=1000)
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Mar 18 22:20:01 localhost cron[10670]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

In the cases when NetworkManager activates a connection correctly and there is no invalid second eth0 connection, the log contains a message like the following:

Mar 16 22:23:47 localhost NetworkManager[6688]: <info>  Auto-activating connection 'eth0'.

Notice there is no such message in the message log above.

The only way I can be sure of preventing NetworkManager creating an invalid second eth0 connection is to disable IPv6 system-wide by uncommenting the line ‘alias net-pf-10 off‘ in the file /etc/modprobe.d/aliases.conf.

So, to me, this looks like a bug in NetworkManager 1.0.0 (I have been experiencing it since Version 0.9.10.0).

More on NetworkManager creating a new connection ‘eth0′ that does not work

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

NetworkManager creates a new connection ‘eth0’ that does not work

Several months ago a new entry ‘eth0’ began appearing under ‘Available connections‘ in the KDE plasma-nm widget (the KDE GUI front-end to NetworkManager) in my Gentoo Linux installation. However, there was already an automatically-created entry ‘Wired connection 1’ for the wired interface. In the plasma-nm GUI I could see that both entries were for the same interface (eth0) and MAC address. My laptop could access the Internet via the connection ‘Wired connection 1’ as usual, but not via the new connection ‘eth0’. And if I deleted ‘eth0’ in the plasma-nm GUI, ‘Wired connection 1’ could not access the Internet until I recreated ‘eth0’ manually.

Apart from the fact that two entries for the same interface is unnecessary, it was annoying because sometimes ‘eth0’ automatically became the active connection instead of ‘Wired connection 1’, despite the fact that only ‘Wired connection 1’ had ‘Automatically connect to this network when it is available’ ticked in the plasma-nm GUI. When this happened, the network icon on the Panel showed an active connection but in fact the laptop could not connect to the Internet. However, the connection did work as expected on the occasions when ‘Wired connection 1’ automatically became the active connection or if I switched manually to ‘Wired connection 1’ via the plasma-nm GUI.

Even more strangely, if I happened to be using WiFi when no Ethernet cable was connected, very occasionally the network icon on the Panel would change from a wireless icon to a wired icon and connection to the Internet would be lost. I would then have to re-select the wireless network in order to reconnect to the Internet.

As my laptop has only one Ethernet port, and as there was previously no ‘eth0’ entry under ‘Available connections‘, initially I thought that the new entry occurred because I had recently installed a new version of udev. I have the parameter net.ifnames=0 in the kernel boot line to stop udev/eudev using the so-called Predictable Network Interface Names, and I have the following udev/eudev rules files relating to networking:

# ls -la /etc/udev/rules.d/*net*
lrwxrwxrwx 1 root root    9 Nov 30 15:25 80-net-setup-link.rules -> /dev/null
# ls -la /lib64/udev/rules.d/*net*
-rw-r--r-- 1 root root  452 Nov  7 09:57 /lib64/udev/rules.d/75-net-description.rules
-rw-r--r-- 1 root root 1734 Jan 28 18:29 /lib64/udev/rules.d/77-mm-huawei-net-port-types.rules
-rw-r--r-- 1 root root  491 Nov  7 09:57 /lib64/udev/rules.d/80-net-name-slot.rules
-rw-r--r-- 1 root root  280 Jan 24 00:41 /lib64/udev/rules.d/90-network.rules

Perhaps udev (well, eudev, as I switched to using eudev after the problem started) did have something to do with the new entry, but I began to suspect that NetworkManager was the culprit. I think the problem first occurred after installing NetworkManager 0.9.10.0 last October, but it remained after I installed NetworkManager 1.0.0, until today when I made the various changes described further on.

I had merged NetworkManager 1.0.0 and preceding versions since 0.9.8.8 with USE flags -dhclient and dhcpcd, i.e. NetworkManager in my installation uses the DHCP client dhcpcd instead of dhclient. (I used to merge NetworkManager to use dhclient but found it did not work with 0.9.8.8 and later versions of NetworkManager.)

The relevant network services running in my installation are as follows, and nothing looks incorrect to me:

# rc-update show | grep -i net
       NetworkManager |      default
                local |      default nonetwork
               net.lo | boot
             netmount |      default
# rc-status | grep -i net
NetworkManager                                                    [ started ]
netmount                                                          [ started ]
# rc-update show | grep dh
# rc-status | grep dh
# rc-update -v show | grep supplicant
wpa_supplicant |
# rc-status | grep supplicant
#

NetworkManager itself launches the DHCP client, so the installation should not be configured to launch a DHCP client. Indeed the output above shows that no DHCP client service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of a DHCP client are not running (they’re not):

# ps -C NetworkManager
  PID TTY          TIME CMD
 6481 ?        00:00:22 NetworkManager
# ps -C dhcpcd
  PID TTY          TIME CMD
10378 ?        00:00:00 dhcpcd
# ps -C dhclient
  PID TTY          TIME CMD
#

As far as WiFi is concerned, NetworkManager itself launches wpa_supplicant, so the installation should not be configured to launch wpa_supplicant. Indeed the output from rc-update and rc-status above shows that no wpa_supplicant service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of wpa_supplicant are not running (they’re not):

# ps -C wpa_supplicant
  PID TTY          TIME CMD
 6491 ?        00:00:00 wpa_supplicant
#

So, as far as I could tell, there was nothing wrong with the non-NetworkManager side of my installation.

I thought the problem might be due to the settings in the file /etc/NetworkManager/NetworkManager.conf, which contained the following:

[main]
plugins=keyfile
dhcp=dhcpcd

[ifnet]
managed=true
auto_refresh=false

[keyfile]
hostname=meshedgedx

I studied the manual pages for NetworkManager.conf:

# man NetworkManager.conf

If I understand correctly, the ifnet plug-in is Gentoo-specific (see References 3, 4 and 5 further on). The entries under [ifnet] in my NetworkManager.conf file were redundant in any case because the ifnet plug-in was not included in the plugins list under [main], so I deleted the entire [ifnet] section. There is no mention of the ifnet plug-in on the NetworkManager.conf manual page or in the Gentoo Linux Wiki article on NetworkManager, and a cursory look in the Gentoo ebuild for NetworkManager 1.0.0 clearly indicates the ifnet plug-in is broken. See, for example, the following comment in the ebuild:

# ifnet plugin always disabled until someone volunteers to actively
# maintain and fix it

and the following warning messages in the ebuild if the user has included ifnet in plugin=<plugin list> in NetworkManager.conf:

ewarn "Ifnet plugin is now disabled because of it being unattended"
ewarn "and unmaintained for a long time, leading to some unfixed bugs"
ewarn "and new problems appearing. We will now use upstream 'keyfile'"
ewarn "plugin."
ewarn "Because of this, you will likely need to reconfigure some of"
ewarn "your networks. To do this you can rely on Gnome control center,"
ewarn "nm-connection-editor or nmtui tools for example once updated"
ewarn "NetworkManager version is installed."
ewarn "You seem to use 'ifnet' plugin in ${EROOT}etc/NetworkManager/NetworkManager.conf"
ewarn "Since it won't be used, you will need to stop setting ifnet plugin there."

I modified NetworkManager.conf to contain the following:

[main]
plugins=keyfile
dhcp=dhcpcd
no-auto-default=eth0

[keyfile]
hostname=meshedgedx

Note that the ifnet plug-in was not specified in the plugins list in the [main] section of my previous NetworkManager.conf so it was not the cause of my problem, but I hoped that adding no-auto-default=eth0 to NetworkManager.conf would solve the problem. I deleted the ‘Wired connection 1’ entry from the plasma-nm GUI, ticked ‘Automatically connect to this network when it is available’ for the ‘eth0’ entry and made sure that option was not ticked for any of the other entries under ‘Available connections‘, then rebooted. There was no longer an entry ‘Wired connection 1’ in the plasma-nm widget GUI, just an entry for ‘eth0’, and the installation connected automatically to the wired network and I could access the Internet, but did not reconnect to the wired network if I removed and reinserted the Ethernet cable when also connected to a wireless network. So I was not home and dry yet.

I have read on various Web sites that NetworkManager prefers wired connections over wireless connections. I assume this is because NetworkManager sets a higher metric for the wired connection.

I am on a work trip at the moment and cannot use a dynamic wired connection, only a static wired connection, but I can see that NetworkManager 1.0.0 does set a higher-priority metric for wired connections:

# # Now with both dynamic wireless and static wired:
# ip route show
default via 10.90.21.1 dev eth0  proto static  metric 100
default via 10.96.0.1 dev wlan0  proto static  metric 600
10.90.21.0/24 dev eth0  proto kernel  scope link  src 10.90.21.112  metric 100
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86  metric 303
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
192.0.2.1 via 10.96.0.1 dev wlan0  proto dhcp  metric 600
#

10.90.21.1 is the IP address of the gateway for the wired connection, and 10.90.21.112 is the IP address of my laptop’s wired interface. The smaller the metric value, the higher the routing priority. Notice that the metric for the eth0 interface is 100 whereas the metric for the wlan0 interface is 600, so it does appear that NetworkManager favours a wired connection over a wireless connection when both are active.

After doing all the above, I came across Debian bug report no. 755202: network-manager: keeps creating and using new connection “eth0” that does not work which appears to be exactly what I was experiencing. Various people posted solutions that worked in their particular circumstances, so I am none the wiser. Gentoo user Keivan Moradi posted message no. 79 on that bug report, about a warning message he found in the NetworkManager log file regarding a file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0, and he then deleted the latter file. I found the same message in /var/log/messages:

# grep networkmanager /var/log/messages
Feb  9 04:10:05 localhost NetworkManager[10355]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing
Feb 11 15:53:05 localhost NetworkManager[13143]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing

The file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 also existed in my installation, so I also deleted it. It was a zero-length file and I do not know if it had anything to do with my problem:

# ls -la /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
-rw------- 1 root root 0 Jan 20 00:09 /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
# rm /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
#

Anyway, the file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 has not reappeared since I deleted it.

Keivan Moradi had ‘id=Wired‘ under [connection] in the file /etc/NetworkManager/system-connections/eth0, and he decided to change the name of the file from ‘eth0‘ to ‘Wired‘. However, in my case the file name and the id in the file /etc/NetworkManager/system-connections/eth0 are both ‘eth0‘:

# cat /etc/NetworkManager/system-connections/eth0
[ethernet]
mac-address=70:5A:B6:3E:C1:8A
mac-address-blacklist=

[connection]
id=eth0
uuid=cb3d5786-f947-44b8-92f7-8471fc94c568
type=ethernet
permissions=
secondaries=

[ipv6]
method=ignore
dns-search=

[ipv4]
method=auto
dns-search=

I had already deleted and recreated the connection ‘eth0’ in the plasma-nm GUI by the time I checked the contents of the directory /etc/NetworkManager/system-connections/ so I do not know if the original file name and id were the same. I had also already deleted the connection ‘Wired connection 1’ in the plasma-nm GUI by the time I checked the contents of the directory; presumably files for connections ‘Wired connection 1’ and ‘eth0’ both existed in /etc/NetworkManager/system-connections/ before then. I do not know why the zero-length file .keep_net-misc_networkmanager-0 was created, but no further files have appeared in the directory since I deleted the connection ‘Wired connection 1’ and the file .keep_net-misc_networkmanager-0.

Keivan Moradi was also previously using a buggy r8169 kernel module (Realtek Ethernet hardware) and switched to using the r8168 module, but I am using a Qualcomm Atheros AR8131 Gigabit Ethernet card and an Intel Corporation Ultimate N WiFi Link 5300 card, so that part of his problem cannot be a factor in my case.

Anyway, as I wrote earlier, I no longer have two connection entries for the wired interface, and NetworkManager no longer creates automatically a second connection entry for the wired interface. And now if I am already connected to a wireless network, NetworkManager connects/reconnects automatically to a wired network with the ‘Automatically connect’ option ticked. So it looks like my problem is completely solved, although I reserve judgement until I have been able to use the laptop in my home network (which has the same router for both wired and wireless connections, whereas the wired network and wireless network are separate networks in the office in which I am now working).

Conclusion

If you had the patience to read all the above, I am impressed! If you also understood it, I am doubly impressed!

To cut a long story short, if you are experiencing a similar problem to mine, I recommend you do the following:

  1. Check that your network driver is reliable. You can search the Web to see if other users have experienced problems with the same driver you are using.

  2. Make sure the contents of NetworkManager.conf are correct. Read the NetworkManager.conf man page and the GNOME Wiki page on NetworkManager settings to find out what options are available.

  3. Delete all the files (i.e. including hidden files) in the directory /etc/NetworkManager/system-connections/ and recreate your connections via either the NetworkManager GUI (e.g. plasma-nm in KDE or nm-applet in GNOME) or NetworkManager TUI (nmtui).

References

  1. man NetworkManager.conf
  2. Gentoo Linux Wiki – NetworkManager
  3. GNOME Wiki – NetworkManager SystemSettings – Configuration Plugins
  4. Gentoo NetworkManager Plugin
  5. Another Gentoo Dev – Ifnet updates for NetworkManager 0.9

UPDATE (March 10, 2015): Well, I was right to reserve judgement until I was able to use my laptop with my home network. I am now back at home and an Ethernet cable is plugged into my laptop’s RJ45 socket. Even with the changes I made, when I boot the laptop NetworkManager sometimes (but not always) has two connections named ‘eth0’, one of them the ‘Active connection’ (but not able to connect to the Internet) and the other an ‘Available connection’. In this situation the wired network icon on the Panel has a yellow question mark superimposed. If I delete the ‘eth0’ active connection and use the other ‘eth0’, the latter works as expected and I have no trouble connecting to the Internet. In Debian bug report no. 755202 (see the link further up) user Frederik Himpe added a comment on March 4, 2015 that he is also still experiencing this problem and “It looks like there is a race somewhere, causing the network interface to be brought up before Network Manager is started, and this prevents correct configuration by NM”. So the problem is still unresolved. Hmm … I wonder if udev does have something to do with it after all.

UPDATE (March 12, 2015): The problem persists. I disabled use of IPv6 in /etc/avahi/avahi-daemon.conf to see if the Avahi daemon has something to do with the problem, but that made no difference. Later I also disabled use of IPv4 in /etc/avahi/avahi-daemon.conf, but that made no difference either. So it looks like the Avahi daemon is not the culprit. Checking via the plasma-nm GUI I notice that the ‘rogue’ eth0 Active connection has IPv4 disabled and IPv6 Link-Local enabled. So why is NetworkManager creating a second eth0 connection just for IPv6 Link-Local? And why on Earth is NetworkManager creating any additional connection at all when NetworkManager.conf contains no-auto-default=eth0? Surely this must be a bug in NetworkManager 1.0.0?

UPDATE (March 17, 2015): I have been investigating the problem further: see my latest blog post for details.