On Sat, 2019-08-17 at 18:46 +0200, roger tarani free fr wrote:
Hi
Hi,
Debian 10/gdb network-manager 1.14.6-2 amd64 network-manager-gnome 1.8.20-1.1 amd64 I create a bridge with nmcli. I delete the previous wired connection. The networking setup is fine and the bridge connection even appears in the GUI Settings/Network Wired section. As confirmed by the CLI: $ nmcli connection show NAME UUID TYPE DEVICE br0 f8cc5703-e3ba-4afb-b7e6- 75fd995cee16 bridge br0 bridge-slave-enp0s25 cef1a1ae-2d51-46b5-aa9d- 81227a8c9be3 ethernet enp0s25 But if I "deactivate" this connection from the GUI, it totally disappears (from the GUI), and the networking setup is put down.
I think most GUIs don't support ~advanced~ device types like a bridge. In any case, that is entirely up to the GUI. This limitation may be intentional (to keep the UX simple). More likely nobody was investing the work to make it happen. Also, since there are multiple GUIs: it always depends on which GUI you are using. On the upside, all client tools of NetworkManager (nmcli, nmtui, GUI) use the same D-Bus API, so if some tool is not well suited for a task, possible there is another.
In fact, it has the same effect as doing 'nmcli connection down bridge-slave-enp0s25' : $ nmcli connection show NAME UUID TYPE DEVICE br0 f8cc5703-e3ba-4afb-b7e6- 75fd995cee16 bridge br0 bridge-slave-enp0s25 cef1a1ae-2d51-46b5-aa9d- 81227a8c9be3 ethernet -- I found two ways for reactivating the bridge connection: $ sudo systemctl restart NetworkManager.service
Restarting NetworkManager.service is almost always the wrong thing to do. That is because when you restart NetworkManager, it tries to keep your interfaces up (so you don't disconnect yourself from the network). But that means, NetworkManager tries hard that there are no actual changes when you restart the service. Of course, there are a lot of changes indeed (like, autoconnect kicking in again). Some of these are desired, some are bugs. But optimally, nothing (undesirable) would change during restart (only desirable things). For example, one "bug" is that during restart NetworkManager forgets that a profile was blocked form autoconnect previously and it might autoconnect it right again. That's why restart seems to activate the bridge profile. That should be fixed to remember that autoconnect is blocked for the profile. So, don't restart NetworkManager if you expect such changes, because that is not what restart does. You may restart NetworkManager to reload certain configuration (but most configuration can be reloaded with `killall -HUP NetworkManager`). Or to update/downgrade the NetworkManager package. Otherwise, use commands like killall -HUP NetworkManager nmcli connection load/reload nmcli connection up/down
or $ nmcli connection up bridge-slave-enp0s25
Right. This is the way. This activates the profile via a D-Bus command.
The networking setup goes up and the bridge connection even appears again in the GUI. Do you know a simple way or a workaround to fix that?
Well, it's certainly an oddity of the GUI -- if not a bug. The workaround is to not use that GUI for this task.
Or should we consider this as a flaw in the network-manager-gnome package that need to be fixed?
Right.
PS When one creates a wired connection from the GUI Setings/Network, if he comes bask and changes some parameters (IP address, ...) then clicks on Apply, it is in fact ONLY saved to a file in /etc/NetworkManager/system-connections/<connection-name> but it is NOT applied. To apply a change, one must click on the slider button to put it down then again to put it up (or use 'nmcli conn down <connection-name> && nmcli conn up <connection-name>' ).
Yes, there is a difference between: - "connection" (aka "connection profile", "profile), which is a bunch of settings. You see them with `nmcli connection`. - "device" (a "networking interface"), which is usually known also to kernel and you see it with `ip link`. See also `nmcli device`. Modifying a connection profile does not take effect automatically on a device that is already up/activated/connected. Comments like nmcli connection up $PROFILE nmcli connection down $PROFILE nmcli device connect $DEVICE nmcli device disconnect $DEVICE activate/deactivate a profile. In any case, that's up to the client-tool (the GUI) to offer this modify-profile + activate in one step. In practice, nmcli and nm-connection-editor don't offer these two steps as one. The user would have to do both steps manually. In fact, nm- connection-editor is entirely unaware of anything related to devices, it only edits connections... Btw, there is also `nmcli device reapply` and `nmcli device set`, which allows you to modify the settings of an active device, without changes to the persisted profile and doing a full down+up cycle.
I had some pain with a new Debian Buster setup before I could figure out what happened there. If this is an expected behaviour? If yes, can you add a warning to explicitly inform the user that he MUST click twice on the down/up slider button for getting the connection down and up and his changes applied?
You talk about "network-manager-gnome" (package) and "nm-applet" (application). Does nm-applet really have slider buttons? Not for me. Maybe you are using gnome-shell? Note that (the network part of) "gnome-shell" offers similar functionality as "nm-applet". Likewise, (the network part of) "gnome- control-center" is similar to "nm-connection-editor". But these are different GUIs. When you talk about a GUI it would be good to be very specific which GUI you are actually using and what exactly you are doing. In any case, this is a GUI problem.
I would clearly prefer to get a button 'Save' and a button 'Save & Apply' (or even a third button 'Just Apply' taht would be nice for quickly testing some parameters - but it would make the GUI a little bit unusual ; or an 'expert mode' could be added)
Right. That would be very nice. Patches welcome :) best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part