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.

About Fitzcarraldo
A Linux user with an interest in all things technical.

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

  1. Fitzcarraldo says:

    Actually, since making this blog post I have found that, very, very occasionally, an invalid second eth0 connection is created even in the following situation:

    IPv6 enabled in aliases.conf: yes
    IPv6 enabled in avahi-daemon.conf: no
    [ipv6] method=ignore
    [ipv4] method=auto
    [ipv4] may-fail=false

    So it seems the only sure-fire way of stopping NetworkManager from creating an invalid second eth0 connection is to disable IPv6 system-wide.

  2. matthijskooijman says:

    I’ve also dug into this issue a bit, see my analysis at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202#326

    I’ve also discovered a cleaner workaround: disable just ipv6 autoconfig by dropping this in `sysctl.conf`:

    net.ipv6.conf.eth0.autoconf=0
    net.ipv6.conf.eth0.accept_ra=0

    This only prevents ipv6 configuration during the initial boot,
    when the boot is complete, eth0 has a complete set of ipv6 addresses as
    well (presumably because NetworkManager handles this).

    • Fitzcarraldo says:

      Thanks for your comment. I personally have not been having the problem in Gentoo (using OpenRC rather than systemd) for a couple of years and I don’t have to disable IPv6 these days. I don’t know which precise version of NetworkManager was installed when the problem stopped happening in my Gentoo installations, but I do know that the problem was not occurring for me in 2016 with NetworkManager 1.9.12-r1 on my Clevo W230SS laptop running Gentoo Stable Branch and 1.2.2 on my Compal NBLB2 laptop running Gentoo Testing Branch. And the problem is also not occurring with the current versions available in my current Gentoo installations (NetworkManager 1.8.4 in Stable and 1.10.2 in Testing). So I had assumed the NetworkManager developers must have fixed the problem. If you’re still seeing the problem in the latest release of Debian and with NetworkManager 1.10.4-1 then I wonder if something else is going on.

  3. matthijskooijman says:

    > If you’re still seeing the problem in the latest release of Debian and with NetworkManager 1.10.4-1

    Yup, I am. However, it seems a particular race condition, that also requires IPv6 configuration to happen before NM starts, so it might very well be that different installations and distros have different timings, and thus do or do not show the problem 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.