GNOME Bugzilla – Bug 743309
Add IpIface and IPIfindex properties to active VPN connections
Last modified: 2020-11-12 14:27:59 UTC
At the present, there is no easy way to match active VPN connections with VPN-generated (TUN/TAP) devices (apart from info put to vpn-up action for dispatcher). The info should be available on D-Bus.
I pushed code to jk/vpn-properties-bgo743309.
There had been talk before about putting the path to the tun/tap D-Bus Device in the second item of the Devices array.
Yeah, that's the plan I had, though it doesn't conflict with this. That plan was that once VPN connections are real NMDevices (eg, dcbw/devices-for-all-1 which I'm still reworking) then we can add parent/child relationships to NMDevices. Thus the tun0 NMDevice would be a child of the VPN device "Whatever VPN", and likewise "wwp0s26f7u2i8" would be a child of "Verizon LTE WWAN", and "ppp0" would be a child of "eth0" for PPPoE. That kind of thing. But if we did the IpIface/IpIfindex properties for the VPN connection, that could still be preserved easily even if we did the child thing above.
Yes, the "VPN devices" and parent/child relationship is good thing to do. But as Dan said it doesn't conflict with these patches. And I think it is useful to have IpIface/IpIfindex properties in the active VPN connection.
The new properties can be displayed on active VPN with $ nmcli con show my-openvpn-profile or D-Bus dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/ActiveConnection/11 org.freedesktop.DBus.Properties.Get string:org.freedesktop.NetworkManager.VPN.Connection string:IpIface or using the new functions in libnm, of course.
I have pushed a fixup to the branch to show the properties in PropertiesChanged signal.
I cannot say if the code is correct or is missing something, but I already tried it and can confirm that it works as expected. I even already tried to use it in our KDE NM applet and I'm happy with the result. I hope this gets merged soon and won't be discarded.
> vpn: add IpIface and IpIfindex D-Bus property to VpnConnection Could we name it IpInterface instead, so it's consistent with NMDevice.IpInterface? The libnm-glib/libnm functions can still be _get_iface() though, to also be consistent with nm_device_get_iface(). Also, perhaps this should just go onto the ActiveConnection interface instead since these properties are common to both NMDevices and NMVPNConnections? I think that might actually work better too, since I eventually want to make NMVPNConnections NMDevice subclasses (after dcbw/devices-for-all-1).
(In reply to comment #8) > Also, perhaps this should just go onto the ActiveConnection interface instead > since these properties are common to both NMDevices and NMVPNConnections? I > think that might actually work better too, since I eventually want to make > NMVPNConnections NMDevice subclasses (after dcbw/devices-for-all-1). Yeah, we need to think about the big picture... We already have Interface and IpInterface on Device, so if we're eventually going to have NMDevices for all VPNs, then having IpInterface on either VPNConnection or ActiveConnection seems wrong. And if we're going to have Ifindex/IpIfindex anywhere, shouldn't it be Device then?
Well, if we have a device for VPNs, and it is possible to associate tun/tap devices with the VPN connection then these patches are redundant. Else (until then) NMVPNConnection seems a better place than ActiveConnection I think.
My plan for this moving forward would be: 1) each VPN connection will create an unrealized NMDeviceVpn object 2) when the VPN is activated, the NMDeviceVpn's Iface/IpIface would become the tunnel interface of the VPN (if any, since IPSec doesn't have one) 3) the NMDeviceVpn's IP4Config/Ip6Config/etc properties would be the same as the NMVPNConnection's currently are; we could acutally juse re-use the same object in memory 4) the NMActiveConnection's "Master" property and the NMDeviceVpn's Master property point to the upper device (eg, eth0/wlan0/etc) 5) if a tunnel device is created, it should be suppressed (eg it doesn't get its own NMDevice) for now, and I think this is already handled by NMManager code. But there's a race condition here, since the VPN daemon will create the tunnel interface before NM gets the tunnel interface name, so it's not available in the manager yet. Not sure how to fix that yet.
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).