I started experiencing this problem in Gentoo Linux (~amd64 installation using OpenRC) around 5 months ago. Keivan Moradi's fix (Message #79) did not cure the problem for me, and, in any case, my wired NIC uses a different driver (atl1c) which appears to be stable in my installation. I think an invalid second eth0 connection started occurring after I upgraded NetworkManager to Version 0.9.10.0, and has continued occurring up to NM 1.0.0.
NetworkManager.conf contains the following: [main] plugins=keyfile dhcp=dhcpcd [ifnet] managed=true auto_refresh=false [keyfile] hostname=meshedgedx In my case, NM usually (but not always) creates an invalid second eth0 connection when my laptop boots. The second eth0 connection is shown as Active in plasma-nm (the KDE front-end for NM) but only has an IPv6 Link-Local connection configured (i.e. IPv4 is disabled). If I click on Disconnect in plasma-nm then this eth0 connection disappears from plasma-nm. Sometimes the valid available connection 'eth0' I configured previously then connects automatically; other times I have to click Connect. Either way, once the invalid IPv6 Link-Local connection has been removed, the valid available connection can connect 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 occurs when NM appears to have first run earlier than syslog-ng started logging. When NM first runs after syslog-ng has started logging, I can see it launches dhcpcd and acquires an IPv4 address. The avahi-daemon does not seem to be the cause of the problem if I understand the log file correctly. I could be misinterpreting what is going on, but that's how it looks to my inexpert eyes. I tried some experiments: 1. I commented out the entire contents of /etc/conf.d/net (the configuration file for init scripts /etc/init.d/net.*) -- which I *think* is analogous to Debian's /etc/network/interfaces -- but it did not stop the invalid second eth0 connection occurring. 2. I added 'use-ipv6=no' and, later, 'use-ipv4=no' in /etc/avahi/avahi-daemon.conf but they did not stop the invalid second eth0 connection occurring. 3. I added 'deny-interfaces=eth0' in /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. 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). 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 left the 'net.lo' service unallocated to a runlevel.] 6. Since the invalid eth0 connection gets allocated an IPv6 Link-Local address rather than an IPv4 address, I tried a work-around: I disabled IPv6 system-wide by uncommenting the line "alias net-pf-10 off" in the file /etc/modprobe.d/aliases.conf. Now no invalid second eth0 connection is created, and the valid eth0 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. Anyway, I would like to find the root cause of the problem, rather than settling for a work-around of disabling IPv6 system-wide. The fact that sometimes a second eth0 connection is not created and the 'good' eth0 connection created previously can connect, hopefully means it should be possible to have both IPv6 and IPv4 enabled without an invalid eth0 connection ever being created. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
