Re: Problem with NM 1.0.12 with some Realtek drivers

2016-04-15 Thread Thomas Haller
On Fri, 2016-04-15 at 12:59 -0500, Larry Finger wrote:
> A number of users are reporting that systems that use NM 1.0.12 are
> unable to 
> connect to USB devices running the Realtek out-of-kernel drivers. It
> appears 
> that 
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=
> 1.0.12&id=a3c0166a2064c41408d1e08defee3a7e4a0ce3f7 
> is the commit causing the problem. If that information is correct,
> then devices 
> with mode equal to NM_802_11_MODE_UNKNOWN are ignored.
> 
> Could someone please tell me the value of NM_802_11_MODE_UNKNOWN?
> 
> Thanks,
> 


Hi,

see https://bugzilla.gnome.org/show_bug.cgi?id=763388
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-0&id=70c0defe753bc98ac75725cc32a84b36f32258e4

Thomas


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Problem with NM 1.0.12 with some Realtek drivers

2016-04-15 Thread Larry Finger
A number of users are reporting that systems that use NM 1.0.12 are unable to 
connect to USB devices running the Realtek out-of-kernel drivers. It appears 
that 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=1.0.12&id=a3c0166a2064c41408d1e08defee3a7e4a0ce3f7 
is the commit causing the problem. If that information is correct, then devices 
with mode equal to NM_802_11_MODE_UNKNOWN are ignored.


Could someone please tell me the value of NM_802_11_MODE_UNKNOWN?

Thanks,

Larry

--
If I was stranded on an island and the only way to get off
the island was to make a pretty UI, I’d die there.

Linus Torvalds
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: howto keep always ipv4ll address

2016-04-15 Thread matti kaasinen
2016-04-15 19:22 GMT+03:00 Thomas Haller :

> Also, "eth0:avahi" sounds more like an interface-alias. That is not a
> separate (real) interface, just one address that is show by ifconfig
> tool as a separate interface (but it isn't). See `ip addr show`.
>


Interface alias is goodenough for me as along as it responds to both
addresses as it does by my experience.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: howto keep always ipv4ll address

2016-04-15 Thread matti kaasinen
2016-04-15 19:28 GMT+03:00 Dan Williams :

> To clarify, not possible on NM 0.9.8.  NM 0.9.10 and later make large
> efforts to preserve configuration made outside NM.
>
> Unfortunately I have to cope with this version for a while. Arago project
just started to work on Yocto version 2.1 that has much newer NM - takes
several months to get stabile release.

>
> But I think it could be handled with dispatcher scripts too that would
> spawn avahi-autoipd --force-bind on the interface that has just been
> upped by NM.
>

OK. Actually this command is what I used as avahi-autoipd start command. I
suppose it is enough just to kill avahi-autoipd as systemd service unit
starting avahi-autoipd has Restart property. However, it is not quite clear
for me, which evet I should hook this kill command.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: howto keep always ipv4ll address

2016-04-15 Thread Dan Williams
On Fri, 2016-04-15 at 18:22 +0200, Thomas Haller wrote:
> On Fri, 2016-04-15 at 13:36 +0300, matti kaasinen wrote:
> > 
> > Hi!
> > 
> > Is there way to tell NM (v.0.9.8.10) not to drop ipv4ll address =
> > eth0:avahi interface.
> I don't think that is possible.

To clarify, not possible on NM 0.9.8.  NM 0.9.10 and later make large
efforts to preserve configuration made outside NM.

> 
> > 
> > It seems that this dropping happens immediately when dhcp lease is
> > gained. What harm it would do just preserving this interface alias?
> When NetworkManager manages a device, it deletes other addresses on
> that interface because it doesn't know why they are there.
> 
> 
> On newer versions of NetworkManager, if you add an address (link-
> local
> or not), after NetworkManager activated the device, it would keep it.
> But also there is a race involved, in that the address must not be
> added before NetworkManager starts configuring the interface
> initially.

This actually sounds like the RFEs we've had for a while to allow
multiple addressing schemes.  eg instead of "link-local only" allow
both "auto" and link-local in parallel.  Maybe?

But I think it could be handled with dispatcher scripts too that would
spawn avahi-autoipd --force-bind on the interface that has just been
upped by NM.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: howto keep always ipv4ll address

2016-04-15 Thread Thomas Haller
On Fri, 2016-04-15 at 13:36 +0300, matti kaasinen wrote:
> Hi!
> 
> Is there way to tell NM (v.0.9.8.10) not to drop ipv4ll address =
> eth0:avahi interface.

I don't think that is possible.


> It seems that this dropping happens immediately when dhcp lease is
> gained. What harm it would do just preserving this interface alias?

When NetworkManager manages a device, it deletes other addresses on
that interface because it doesn't know why they are there.


On newer versions of NetworkManager, if you add an address (link-local
or not), after NetworkManager activated the device, it would keep it.
But also there is a race involved, in that the address must not be
added before NetworkManager starts configuring the interface initially.


Basically, NM doesn't know, what to do with this address and deletes
it.



Also, "eth0:avahi" sounds more like an interface-alias. That is not a
separate (real) interface, just one address that is show by ifconfig
tool as a separate interface (but it isn't). See `ip addr show`.



Thomas

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)

2016-04-15 Thread Dan Williams
On Fri, 2016-04-15 at 15:24 +0200, Dave Conroy wrote:
> 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,

Which desktop environment are you using?  Can you screenshot the place
that you think the disconnect option should be showing up but isn't?
 There are a bunch of different UIs for NM, and only one is actually
written by NM developers :)  Know which UI would help us direct the bug
report to the right place, or fix it ourselves if it's in nm-applet.

Thanks!
Dan

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

Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)

2016-04-15 Thread Dave Conroy
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 

Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)

2016-04-15 Thread Thomas Haller
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/

signature.asc
Desc

Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)

2016-04-15 Thread Dave Conroy
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. 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.

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/

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


howto keep always ipv4ll address

2016-04-15 Thread matti kaasinen
Hi!

Is there way to tell NM (v.0.9.8.10) not to drop ipv4ll address =
eth0:avahi interface. It seems that this dropping happens immediately when
dhcp lease is gained. What harm it would do just preserving this interface
alias?

Thanks,
Matti
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Allow Single connection only via networkmanager-openvpn (reuse tun0?)

2016-04-15 Thread Thomas Haller
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

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list