GNOME Bugzilla – Bug 733644
re-activating a master connection, should re-activate the auto-connect slaves that were up before
Last modified: 2020-11-12 14:34:09 UTC
So this was a bit hard to summarize, but relatively easy to describe. To reproduce, boot a Fedora live image with an ethernet cable connected, so you have an NM-generated "Wired connection 1" profile. Now set up ifcfg files describing a bridged connection, using the same ethernet connection. I've been doing this by installing virt-manager, disabling the ethernet connection, and using virt-manager's UI to create a bridge, but you could also do it manually. Upshot is you end up with /etc/sysconfig/network-scripts/ifcfg-br0 and /etc/sysconfig/network-scripts/ifcfg-eth0 (or whatever) describing a correct, basic bridged connection. Now run 'nmcli con reload' and 'nmcli con show' and you'll see three relevant profiles: "Bridge br0", "Wired connection 1", and "System eth0", where "Wired connection 1" is the auto-generated, non-bridge-involved profile for the eth0 interface, and "System eth0" is the bridge slave profile for the same interface. If you now do 'nmcli con up (UUID of Bridge br0)' then 'nmcli con up (UUID of System eth0)', you'll get an error with the first command (see https://bugzilla.gnome.org/show_bug.cgi?id=733641 ), but your bridge will come up properly. If you do it the other way around, though, something odd happens. If you do 'nmcli con up (UUID of System eth0)' first, it'll succeed, and 'nmcli con show' will list it (not 'Wired connection 1') as having the eth0 interface. If you then call 'nmcli con up (UUID of Bridge br0)', something odd happens: the 'active' connection for the eth0 interface (the one listed as having the interface in 'nmcli con show') is immediately flipped from 'System eth0' to 'Wired connection 1'! And obviously, the bridge doesn't come up correctly. I can't see any reason why NM should do this, it seems like a bug. This is with a Fedora Rawhide 2014-07-23 Workstation x86_64 live image, NetworkManager-0.9.10.0-1.git20140704.fc22.1.x86_64 .
When you `nmcli connection up` a connection that is already active, NM is supposed to down and re-up the connection. If an other connection is already active, it is supposed to down that connection. If you down a connection, NM searches for applicable autoconnect connections and choose one to autoconnect on the device -- this is different from `nmcli device disconnect`, where not auto connect will be done. I suspect the following happens: If you do `nmcli con up System\ eth0`, it will up the slave + the bridge master (as you saw). If you call up on the already activated bridge, it will down the bridge and its slave, only to reactivate the bridge again. At the moment when eth0 becomes disconnected (after downing the bridge), 'System eth0' is not eligible for autoconnect (because the master is down), hence it chooses 'Wired connection 1' I agree this is an unexpected behavior. I think this bug is related to bug 730492 (but not the same). Probably they should be solved together, therefore I am setting "depends on" for easier tracking.
"If you do `nmcli con up System\ eth0`, it will up the slave + the bridge master (as you saw)" I don't think it did, no. I think it only brought up the slave, and the bridge wasn't up at that point. But I'll try and re-test later.
(In reply to comment #2) > "If you do `nmcli con up System\ eth0`, it will up the slave + the bridge > master > (as you saw)" > > I don't think it did, no. I think it only brought up the slave, and the bridge > wasn't up at that point. But I'll try and re-test later. you cannot have a slave active without a master. When you activate a slave, it will tear up the master as well (unless already activate). Also, downing the master, will down the slave. Hm, actually, NM downs bridge and slave, and wants to autoconnect an eligible connection on the device. The bridge-slave is not eligible (even if it is autoconnect), because the bridge-master is currently deactivating in that moment. So, another connection will be chosen instead (or none). Maybe, a better behaviour would be, if NM downs a bridge, and we know that we want to reactivate it immediately again, that the master is considered available, and the bridge-slave be eligible for autoconnect. I think non-autoconnect slaves OTOH should not be reconnected when going through a down/up cycle in the master. I changed the bug subject (if you agree).
(I was wrong, this is not really related to bug 730492)
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).