GNOME Bugzilla – Bug 791985
"interface-name=ppp0" causes connection to disappear
Last modified: 2020-11-12 14:33:08 UTC
Created attachment 366017 [details] A connection sample with the "interface-name=ppp0" After adding the line "interface-name=ppp0" (which nm-connection-editor did for me automatically upon editing an existing connection) nm-applet does not show the connection anymore. Removing the line and reloading configs fixes the problem. # Steps to reproduce: 1. Create a new DSL/PPPOE connection and write into "DSL/PPPoE → PPP interface" field "ppp0" (alternatively place the sample I attached to `/etc/NetworkManager/system-connections/` directory). 2. Stop nm-applet if it's running, and execute `nmcli con reload` to reload configs. 3. Execute `nmcli con show`, and check that the connection is handled by networkmanager. 4. Exexute nm-applet, and search the connection there. # Expected The connection should be present in the list of nm-applet # Actual The connection is not present in nm-applet. # Additional info The problem exist both with 1.8.11 and git f48d8b17.
Which version of the NM daemon do you have installed?
(In reply to Beniamino Galvani from comment #1) > Which version of the NM daemon do you have installed? $ NetworkManager --version 1.10.2-1, Arch Linux $ nmcli --version nmcli tool, version 1.10.2-1, Arch Linux
In versions of NM prior to 1.10, PPPoE connections could only be activated on Ethernet devices and the connection would take "ownership" of the device (in the sense that you could not also activate an Ethernet connection at the same time if PPPoE was already active). Now, PPPoE connections have a pppoe.parent property in which you specify the parent device (Ethernet, or any other supported type) and so it's possible to use them while another connection is active on the device; 'interface-name' is the name of the generated PPP interface. The applet does not understand the pppoe.parent and only looks at interface-name property of the connection to determine if it can be activated on a device. That's why the connection is not shown in the menu. I think it would be a problem to show the PPPoE connections under the device because, once the connection is activated, the applet is not able to show multiple active connections for a single device. Instead, if we want to still support PPPoE connections from the applet, we could add a new 'PPPoE' submenu similar to the VPN one.
Created attachment 371638 [details] [review] [PATCH] editor: allow creating pppoe connections without parent interface In alternative, we can do this and allow the user to choose whether to create a connection that "claims" the parent interface (and can be used by the applet), or a PPPoE connection that works on every interface type but is not supported by nm-applet. Adding support in the applet for this new-style pppoe-connections is non trivial because it breaks existing assumptions.
(In reply to Beniamino Galvani from comment #4) > Created attachment 371638 [details] [review] [review] > [PATCH] editor: allow creating pppoe connections without parent interface lgtm. Do you think nm-applet should also be extended (in a later commit) to support a PPPoE submenu?
(In reply to Thomas Haller from comment #5) > (In reply to Beniamino Galvani from comment #4) > > Created attachment 371638 [details] [review] [review] [review] > > [PATCH] editor: allow creating pppoe connections without parent interface > > lgtm. Thanks, applied to master. > Do you think nm-applet should also be extended (in a later commit) to > support a PPPoE submenu? Yes, I think it's something we want to do eventually, but it requires some effort.
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).