You are right, a Pre Activaition would solve the issue. I spent the past 2 hours working with the pre-up and vpn-up statuses and found that the tun0 device wouldn't release properly as the openvpn binary is launched before the hook is triggered.
Fun exercise though. However, all is not lost: /usr/lib/NetworkManager/VPN/nm-openvpn-service.name supports-multiple-connections=false *does* actually enforce a single connection rule, forcing the user to disconnect from the VPN first before launching another one. I can live with that. Out of curiousity I'm going to try giving latest gnome3 a spin and see if I can solve my (perceived) interface quirks. Thanks for your time, Dave On 15/04/16 03:09 PM, Thomas Haller wrote: > On Fri, 2016-04-15 at 13:13 +0200, Dave Conroy wrote: >> Hi Thomas, >> That explains it, thank you very much - you are correct in what I am >> looking after. >> There doesn't seem to be a working disconnect option in my version of >> NetworkManager (1.193). I will try different GTK themes to see if it >> is a problem with the theme itself. > Certainly NetworkManager, its D-Bus API, and `nmcli connection > disconnect` support disconnecting a VPN connection. If your UI doesn't > allow for that, it's a UI limitation/decision. > > I don't think GTK themes help there. Are you using the gnome-shell > (Gnome3) NetworkManager integration? I am not familiar with how that > works there, maybe there is no disconnect button? That would be > strange... > >> Would there by chance be pre/post hooks that I could utilize to >> execute before the connection is made? I could write up a script that >> disconnects any active connection this way. > There are dispatcher scripts. First, ensure to have the dispatcher > service running: > `systemctl enable NetworkManager-dispatcher.service` > Then place scripts to /etc/NetworkManager/dispatcher.d. > > See `man NetworkManager` for the events there. > > Note that the events `pre-up` and `pre-down` are special (because they > block the device transition, we only want to call scripts there, which > opt-in for those events. See the manual. > > > Note, that `pre-up` might be a place to disconnect the other > connection. The problem here is, that the (blocking) pre-up event is > not emited ~before starting with activation~, but before ~declaring the > device/VPN as fully up~ (but at that point, the VPN connection is > already up for most of the part). > So, if your VPN connections all want to use tun0, you cannot avoid > that. > > > > I guess, it would be a nice feature to have such ~conflicting > connection`. But well... > > An alternative feature would be a "pre-activation" dispatcher event... > > > Thomas > > >> Thanks for the prompt response, >> Dave >> >> On 15/04/16 12:15 PM, Thomas Haller wrote: >>> Hi Dave, >>> >>> >>> On Fri, 2016-04-15 at 06:04 +0200, Dave Conroy wrote: >>>> I've just subscribed to a VPN service that has multiple >>>> locations, >>>> and imported all the necessary .ovpn files into Network Manager. >>>> It seems that I do not have the option to disconnect from the >>>> VPNs >>>> when connected, and upon choosing another location it creates >>>> another >>>> tun device. >>> You mean, you would like to have a configuration option in your VPN >>> "connection", so that when activating another specific VPN >>> connection, >>> the former gets automatically disconnected? >>> >>> No, NetworkManager doesn't have a concept of ~conflicting~ >>> connections. >>> When you activate connection A, you'd have to manually disconnect >>> connection B. >>> >>> >>>> I've made the change to no success to >>>> /etc/NetworkManager/VPN/openvpn-service.name >>>> supports-multiple-connections=false >>>> Yet it still connects multiple locations without disconnecting >>>> the >>>> previous connection. >>> That shouldn't happen. Did you restart NM after changing the file? >>> But >>> I suspect the file /etc/NetworkManager/VPN/openvpn-service.name is >>> ignored and instead it uses /usr/lib/NetworkManager/VPN/openvpn- >>> service.name. The file in /etc only exists for backward >>> compatibility, >>> in 1.2, the location of this file moved to /usr/lib. >>> >>> Changing supports-multiple-connection=false actually should give >>> you >>> the conflicting behavior, but that doesn't sound like the right >>> approach. First of all, openvpn-service.name is not user- >>> configuration. >>> This setting is here to tell NetworkManager that this plugin is new >>> enough to support multiple activations of Openvpn connections >>> (simultaneously). It's not here to implement ~conflicting >>> connections~. >>> >>> Before 1.2, VPN plugins did not support to activate more then once >>> at a >>> time. Old plugins were always supports-multiple-connections=false. >>> >>> >>>> Furthermore, I've set it to specifically use tun0 for my >>>> connections >>>> yet upon trying to load another connection even after "disabling" >>>> the >>>> VPN (I use Cinnamon Desktop) it says that it cannot access tun0 >>>> as >>>> the device is busy. I can disconnect via nmctl >>> Yes, you can disconnect with nmcli. >>> >>>> but was wondering if there was a way that I could force >>>> NetworkManaager to only use one VPN connection at a time, >>>> releasing >>>> back tun0 to be used again. >>> No, such a concept doesn't exist (up to now). >>> >>> >>>> Error Code: >>>> ERROR: Cannot ioctl TUNSETIFF tun0: Device or resource busy >>>> (errno=16) >>> openvpn said that? Yes, that sounds expected, right? >>> >>> >>> >>> Thomas >> >> -- >> Dave Conroy (d...@tiredofit.ca) PGP: 0x45C0F342 >> Pedaling around the world away from a job in Information Technology >> Tired of I.T! http://www.tiredofit.ca The Book - Now available! >> http://www.tiredofit.ca/book/ -- Dave Conroy (d...@tiredofit.ca) PGP: 0x45C0F342 Pedaling around the world away from a job in Information Technology Tired of I.T! http://www.tiredofit.ca The Book - Now available! http://www.tiredofit.ca/book/
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
