Today I installed Leap 42.3 on my laptop.
I had a problem renaming the Ethernet card to eth0, as shown in this thread , and, by adding the line
ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
to /etc/udev/rules.d/70-persistent-net.rules, I managed to rename it.
Unfortunately, if I then go to the Connection Editor and change the Cloned MAC Address to what I want, the connection starts to oscillate between
connection and disconnection many times a minute.
If I don’t change the MAC, it works, but that’s not what I need.
Briefly (and I have no idea how) it worked (i.e. ifconfig -a reported the cloned MAC AND the connection was working).
However, after reboot, it started oscillating again.
I just discovered that, when typing ifconfig -a I can get either the original or the changed MAC address : this probably means that the MAC address is oscillating also.
Another piece of information : if I use the Network Settings to change to Wicked and then back to Network Manager, then it works and ifconfig -a reports the changed MAC (and the card is eth0).
This seems like a workaround but changing to Wicked and back is very slow and the laptop fan goes on when this happens.
Any idea of what’s going on ?
I’ve done more tests and I can say the following :
After booting there are two different processes that fight each other by turning on and off the connection when the Ethernet card has been renamed to eth0 and the MAC address changed. This happens continuously and indefinitely with messages about connecting and disconnecting appearing one after the other.
Switching from the Network Manager to Wicked and then to Network Manager again the connection starts working fine with the eth0 name and the changed MAC. I can do that consistently. Both wired and wireless work.
With Wicked on, there’s no connection. Neither wired nor wireless work.
If I simply turn off the Network Services and then on again, then it doesn’t work. It has to go through Wicked.
I am relieved that it is possible to have eth0 and a new MAC BUT the problem with 2) is the time it takes (a few minutes every time I boot) and the fact that it is a manual operation.
There has to be a better way to do this. Hopefully someone has a clue of what’s going on.
I don’t normally use cloned MAC addresses, but I changed the interface name in a similar fashion and then configured NM to set a cloned MAC address. It did indeed take several attempts to establish a DHCP connection, but it eventually got there. I didn’t need to do anything other than wait, and I observed the NetworkManager journal logging in a terminal during the connection process…
May 16 20:46:21 linux-kgxs NetworkManager[834]: <info> connectivity: check for uri 'http://conncheck.opensuse.org' failed with 'Error resolving 'conncheck.opensuse.org': Temporary failure in name resolution'
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> (p1p5): Activation: starting connection 'DHCP' (c702075a-1425-4e98-b23a-7fa67abf51a1)
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now CONNECTING
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> (p1p5): set MAC address to 00:00:00:00:1E:FE
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> (p1p5): link disconnected (deferring action for 4 seconds)
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: prepare -> config (reason 'none') [40 50 0]
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: config -> ip-config (reason 'none') [50 70 0]
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> Activation (p1p5) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 16 20:46:23 linux-kgxs NetworkManager[834]: <info> dhclient started with pid 1975
May 16 20:46:25 linux-kgxs NetworkManager[834]: <info> (p1p5): link connected
May 16 20:47:09 linux-kgxs NetworkManager[834]: <warn> (p1p5): DHCPv4 request timed out.
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): DHCPv4 state changed unknown -> timeout
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): canceled DHCP transaction, DHCP client pid 1975
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): DHCPv4 state changed timeout -> done
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now DISCONNECTED
May 16 20:47:09 linux-kgxs NetworkManager[834]: <warn> (p1p5): Activation: failed for connection 'DHCP'
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: failed -> disconnected (reason 'none') [120 30 0]
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): reset MAC address to 08:00:27:36:86:14
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): link disconnected
May 16 20:47:09 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
May 16 20:47:09 linux-kgxs NetworkManager[834]: <warn> (pid 1975) unhandled DHCP event for interface p1p5
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): link connected
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> Auto-activating connection 'DHCP'.
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): Activation: starting connection 'DHCP' (c702075a-1425-4e98-b23a-7fa67abf51a1)
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now CONNECTING
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): set MAC address to 00:00:00:00:1E:FE
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): link disconnected (deferring action for 4 seconds)
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: prepare -> config (reason 'none') [40 50 0]
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: config -> ip-config (reason 'none') [50 70 0]
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> Activation (p1p5) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 16 20:47:11 linux-kgxs NetworkManager[834]: <info> dhclient started with pid 1986
May 16 20:47:13 linux-kgxs NetworkManager[834]: <info> (p1p5): link connected
May 16 20:47:56 linux-kgxs NetworkManager[834]: <warn> (p1p5): DHCPv4 request timed out.
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): DHCPv4 state changed unknown -> timeout
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): canceled DHCP transaction, DHCP client pid 1986
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): DHCPv4 state changed timeout -> done
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now DISCONNECTED
May 16 20:47:56 linux-kgxs NetworkManager[834]: <warn> (p1p5): Activation: failed for connection 'DHCP'
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: failed -> disconnected (reason 'none') [120 30 0]
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): reset MAC address to 08:00:27:36:86:14
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): link disconnected
May 16 20:47:56 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): link connected
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> Auto-activating connection 'DHCP'.
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): Activation: starting connection 'DHCP' (c702075a-1425-4e98-b23a-7fa67abf51a1)
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now CONNECTING
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): set MAC address to 00:00:00:00:1E:FE
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): link disconnected (deferring action for 4 seconds)
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: prepare -> config (reason 'none') [40 50 0]
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: config -> ip-config (reason 'none') [50 70 0]
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> Activation (p1p5) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 16 20:47:58 linux-kgxs NetworkManager[834]: <info> dhclient started with pid 1991
May 16 20:48:00 linux-kgxs NetworkManager[834]: <info> (p1p5): link connected
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> address 192.168.1.23
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> plen 24 (255.255.255.0)
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> gateway 192.168.1.1
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> server identifier 192.168.1.1
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> lease time 86400
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> nameserver '192.168.1.1'
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> domain name 'Home'
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> (p1p5): DHCPv4 state changed unknown -> bound
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> (p1p5): device state change: secondaries -> activated (reason 'none') [90 100 0]
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now CONNECTED_LOCAL
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> NetworkManager state is now CONNECTED_SITE
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> Policy set 'DHCP' (p1p5) as default for IPv4 routing and DNS.
May 16 20:48:03 linux-kgxs dns-resolver[2043]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched...
May 16 20:48:03 linux-kgxs dns-resolver[2045]: You can find my version in /etc/resolv.conf.netconfig
May 16 20:48:03 linux-kgxs NetworkManager[834]: <13>May 16 20:48:03 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched...
May 16 20:48:03 linux-kgxs NetworkManager[834]: <13>May 16 20:48:03 dns-resolver: You can find my version in /etc/resolv.conf.netconfig
May 16 20:48:03 linux-kgxs NetworkManager[834]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched...
May 16 20:48:03 linux-kgxs NetworkManager[834]: You can find my version in /etc/resolv.conf.netconfig ...
May 16 20:48:03 linux-kgxs NetworkManager[834]: <info> (p1p5): Activation: successful, device activated.
Not sure why several attempts occur before a successful connection is established though. A bug report may be required.
BTW, if I change to Wicked, it doesn’t work at all.
That probably has more to do with making sure that a suitable config file exists (ie /etc/sysconfig/network/ifcfg-eth0). This can be done via YaST Network Settings.
Thanks. Looking at your log, it looks like it took less than 2 minutes to stabilize. I think I left it there for a while (not sure I how long ) but I’m pretty sure that it was quite a bit longer than that and it kept doing.
BTW, I screwed up the installation of the Nvidia drivers and I ended-up re-installing everything. I now got them working and I will have to re-visit this and, hopefully, it’ll work at least as well as before. Fingers crossed.
Well, after the re-install, I got the Nvidia drivers going but I can’t reproduce what I did before and it is now happily oscillating indefinitely between connection and disconnection with the renamed eth0 card and MAC cloning. Switching between Wicked and NM no longer does the trick. I really wonder what I did before…
When off, the MAC is the original MAC. When on the MAC is the changed MAC.
Now, when I switch back and forth to NM, I get a small Error window with a “No Network Running” and I can only press ok, it then goes into the on-off oscillation.
BTW, I’m sure that before the Ethernet card was set to static IP address. I did change it to DHCP in desperation. No idea what the difference is.
Unfortunately I can’t change it back. When I go to Wicked (the only time the Overview menu is available). Even if I change back to static (subnet mask 255.255.255.0 whatever that means) and press ok, it stays exactly the same (i.e. it ignores my attempt to set IP static again).
At this point I messed up with the settings so much I’m not sure what they are supposed to be,
Needless to say this is an unmitigated disaster. At least it was sort of working before…
Thanks for your help and replies. I might do that. However I have found various references that specifically advice against renaming a card eth0. If I remember correctly one mentioned “races between udev and the kernel”. Another one said “you obviously should not rename your card eth0” without additional explanations.
Yes, probably best to choose another meaningful name as advised in the freedesktop page…or stay with the default name perhaps. Since you’re using openSUSE 42.3, I’m a little perplexed as to why your interface appears to be using predictable naming in the first place. (For reference, my laptop with a single wired interface is using eth0 by default.) Predictable network interface naming will however be used in openSUSE Leap 15 as it already is in TW…
Tumbleweed has been using ‘predictable network interface names’ for some time now and it fits most regular use cases. Inspired or following the scheme idea introduced by ‘biosdevname’, Predictable Network Interface Names was adopted in systemd/udev v197 trying to solve an historical problem with the non deterministic classic naming scheme for network interfaces (eth0, eth1, eth2 …)
Basically it will assign fixed names based on firmware, topology, and location information making them stable between system reboots, hardware additions or removals and also between kernel or drivers updates.
For the upcoming SLE15, we are giving predictable network interface names a try (they are disabled in SLE12 and openSUSE Leap 42.x). For us that turned to be a problem because our AutoYaST testsuite dynamically creates new virtual machines on every system reboot (instead of really rebooting the virtual machine created in the previous step). So from the point of view of the operating system being tested, all the network devices are replaced by new ones in every reboot and that drives the network settings nuts.
That was only our case (arguably “our fault”), but there might be other situations in which going back to the old naming scheme (with names like ‘eth0’) would be more convenient than adapting the preexisting AutoYaST profiles to the new one. In such cases you still can use the old scheme (not fully predictable but very well known by Linux veterans) by just booting the SLE15 installation with this parameters.
I most certainly did not choose it myself. It was there during installation and I could not change it.
And, BTW, unless my stuffing around has changed something else, even when reverting to p5p1, cloning the MAC still results in oscillating on-off.
The renaming to eth0 doesn’t seem to be the problem.
So, maybe a bug, unless I did something that indirectly caused it. The only way to make sure would be to re-install once more and I’m not going to do that.
Thanks everyone.
