Re: nm-applet: trouble with bridge connections

On Sat, 2019-08-17 at 18:46 +0200, roger tarani free fr wrote:


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     
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     
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

  $ 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?


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
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

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 &
(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 :)


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]