GNOME Bugzilla – Bug 770370
Changing cloned MAC address of wired/ethernet leads to disconnect after loss of carrier for more then 4 seconds
Last modified: 2020-11-12 14:32:09 UTC
With the new NetworkManager 1.4 on ARchLinux, I have tried adding ethernet.cloned-mac-address=random to the [connection] section in NetworkManager.conf, and this result in the network connection not working at all. Using wifi.cloned-mac-address=random for the wifi one do work fine and I can see the mac address is randomized. Here is what I can see in the journalctl logs: kernel: tg3 0000:0e:00.0 enp14s0: Flow control is on for TX and on for RX kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp14s0: link becomes ready NetworkManager[661]: <info> [1472075349.6928] manager: NetworkManager state is now CONNECTING NetworkManager[661]: <info> [1472075349.7008] device (enp14s0): set-hw-addr: set-cloned MAC address to 7A:96:18:3E:82:00 (random) NetworkManager[661]: <info> [1472075349.7256] device (enp14s0): state change: prepare -> config (reason 'none') [40 50 0] kernel: IPv6: ADDRCONF(NETDEV_UP): enp14s0: link is not ready NetworkManager[661]: <info> [1472075349.7312] device (enp14s0): state change: config -> ip-config (reason 'none') [50 70 0] NetworkManager[661]: <info> [1472075349.7316] dhcp4 (enp14s0): activation: beginning transaction (timeout in 45 seconds) kernel: IPv6: ADDRCONF(NETDEV_UP): enp14s0: link is not ready kernel: tg3 0000:0e:00.0 enp14s0: Link is down NetworkManager[661]: <info> [1472075354.4570] device (enp14s0): state change: ip-config -> unavailable (reason 'carrier-changed') [70 20 40] NetworkManager[661]: <info> [1472075354.4794] dhcp4 (enp14s0): canceled DHCP transaction NetworkManager[661]: <info> [1472075354.4794] dhcp4 (enp14s0): state changed unknown -> done NetworkManager[661]: <info> [1472075354.4912] device (enp14s0): set-hw-addr: reset MAC address to 65:03:62:45:8A:FD (deactivate) NetworkManager[661]: <info> [1472075354.5024] manager: NetworkManager state is now DISCONNECTED
Hi, it seems that the device goes down afterwards. please attach logfiles with level=TRACE enabled. (possibly, redact your permantent MAC address and other sensitive data if you worry about that) Thanks
Created attachment 334127 [details] NetworkManager log
I've added the logfile.
thanks for the logs. to change the MAC address, the interface must be brought down (line 59). Afterwards, NM brings the interface up again (line 89). You see that the link changes (line 203): platform: signal: link changed: 2: enp14s0 <UP;broadcast,multicast,up,r... but what is missing is "<UP,LOWER_UP; ...", that is: carrier doesn't return. 4 seconds later (line 146), NM decides that the cable is unplugged and brings down the device. later (line 256), you see that carrier is on again. Could it be that you are behind a switch that unplugs you due to the MAC address change? Or maybe it runs some spanning-tree protocol after it notices a new MAC address? Or maybe it's a driver issue? You may get away with it by configuring [main] ignore-carrier=interface-name:enp14s0 but that has other undesired effects, like the device will not autoconnect when you plug-in the cable and it will not disconnect when you unplug the cable. Also, the setting is per-device, not per-connection. So it does not only affect your connection 'Ethernet connection', but all connections on enp14s0. What does `dmesg` and the kernel log say at that time?
Really looks like a driver issue. Let's see what dmesg says. And what is your kernel version? Distro is Arch, but did you compile anything yourself? Some drivers seem only allow you to scramble certain bits of the MAC address. E.g. to quote the private bug: https://bugzilla.redhat.com/show_bug.cgi?id=1318789#c0 4) drivers that restrict unicast address contents (mv643xx which requires the UC address to match the top 44 bits of the device MAC address, otherwise uses promiscuous mode) you could achieve that by setting [device-enp14s0] match-device=interface-name:enp14s0 wifi.generate-mac-address-mask=FF:FF:FF:FF:FF:F0 in NetworkManager.conf (see `man nm-settings` and `man NetworkManager.conf`)
(In reply to Thomas Haller from comment #5) > you could achieve that by setting > > [device-enp14s0] should be: [connection-enp14s0]
There is no switch, my laptop is directly connected to the internet box. My kernel is 4.7.1-1-zen, I didn't compile anything myself. I can confirm that it connects fine with ignore-carrier=interface-name:enp14s0. dmesg/kernel logs just show the same few lines all the time: [ 949.990379] tg3 0000:0e:00.0 enp14s0: Link is up at 100 Mbps, full duplex [ 949.990383] tg3 0000:0e:00.0 enp14s0: Flow control is on for TX and on for RX [ 950.023908] IPv6: ADDRCONF(NETDEV_UP): enp14s0: link is not ready [ 950.045695] IPv6: ADDRCONF(NETDEV_UP): enp14s0: link is not ready [ 950.993635] tg3 0000:0e:00.0 enp14s0: Link is down I think you meant ethernet.generate-mac-address-mask=FF:FF:FF:FF:FF:F0, not wifi.generate-mac-address-mask=FF:FF:FF:FF:FF:F0, right?
(In reply to Zapdos from comment #7) > There is no switch, my laptop is directly connected to the internet box. My > kernel is 4.7.1-1-zen, I didn't compile anything myself. > > I can confirm that it connects fine with > ignore-carrier=interface-name:enp14s0. > > dmesg/kernel logs just show the same few lines all the time: > > [ 949.990379] tg3 0000:0e:00.0 enp14s0: Link is up at 100 Mbps, full duplex > [ 949.990383] tg3 0000:0e:00.0 enp14s0: Flow control is on for TX and on > for RX > [ 950.023908] IPv6: ADDRCONF(NETDEV_UP): enp14s0: link is not ready > [ 950.045695] IPv6: ADDRCONF(NETDEV_UP): enp14s0: link is not ready > [ 950.993635] tg3 0000:0e:00.0 enp14s0: Link is down when you connect with ignore-carrier and random MAC address, does the link eventually come up again if you wait longer then 4 seconds? How long does it take? > I think you meant ethernet.generate-mac-address-mask=FF:FF:FF:FF:FF:F0, not > wifi.generate-mac-address-mask=FF:FF:FF:FF:FF:F0, right? you are correct.
The mask is not actually helpful, same issue. This was actually the first thing I tried before making the bug report. I don't think my driver has such limitation anyway, if I use ignore-carrier=interface-name:enp14s0 I can connect with any randomized mac address. > when you connect with ignore-carrier and random MAC address, does the link > eventually come up again if you wait longer then 4 seconds? How long does it > take? With ignore-carrier, it seems to take a longer time to connect, it seems that the link comes back up 14s later according to the logs.
(In reply to Zapdos from comment #9) > > when you connect with ignore-carrier and random MAC address, does the link > > eventually come up again if you wait longer then 4 seconds? How long does it > > take? > > With ignore-carrier, it seems to take a longer time to connect, it seems > that the link comes back up 14s later according to the logs. the timeout of 4 seconds is not configurable for now, and I doubt it should. 4 seconds is already a very long time. https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device.c?id=c930b7b4fe986da0ccca8b2d1d38eb92a01ced1d#n1676
Are there any alternatives?
ignore-carrier might work well enough for you. I assume it's a driver issue (or bug). I'd try to investigate that.
I guess I'll have to use that setting then, as I think it's unlikely that it will get fixed if it's a driver bug, considering I'm the only reporter.
https://bugzilla.gnome.org/show_bug.cgi?id=673334#c8 : quoting dcbw: > Changing the MAC address might re-init the device firmware and require another > autonegotiation with the peer. Sometimes that takes a while, and yeah, that > might mean the device looses a carrier for longer than 4 seconds. I guess we > probably need to increase that timeout if the device is in the middle of > activating a connection where the MAC address is changed.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).