On Tue, 2016-02-02 at 23:09 +0100, Adrian Freihofer wrote:
> Hi Dan
>
> This is my VPN connection configuration:
> settings = {u'connection': {u'type': u'vpn',
> u'autoconnect': True,
'autoconnect' of VPN connections has no effect (but doesn't hurt
either).
> u'zone': 'trusted'},
> u'vpn': {u'service-type':
> u'org.freedesktop.NetworkManager.openvpn',
> u'data': {u'cert-pass-flags': u'4',
> u'connection-type': u'tls',
> u'remote-cert-tls': u'server',
> ... + credentials and other details
> ...
> }
> },
> u'ipv4': {u'method': u'auto',
> u'may-fail': False,
> u'never-default': True
> },
> u'ipv6': {u'method': u'ignore'},
> }
>
> Finally the connection is activated by:
> NetworkManager.ActivateConnection(connection, '/', '/')
>
> My assumptions (which were true for NM 0.9...):
> - The first '/' means "auto select the device"
> - As soon as NM is connected it will try to setup the VPN connection
> because of the autoconnect=true flag in the VPN configuration.
when you activate a VPN connection, it does not automatically connect
another device.
It tries to activate only the VPN connection. A
prerequisite for that is that another device is connected.
> With NM 1.0.10: For WLAN and for Ethernet devices it works as
> expected (by me), but for GSM devices the VPN connection is not
> automatically
> established e.g. after rebooting the system.
> What do you exactly mean with set as a "secondary" of wwan? How do I
> need to change my configuration?
As said, autoconnect doesn't work for VPNs. But you can set the vpn
connection as "secondary" for another connection.
E.g. modify your Wi-Fi connection to activate your VPN connection when
the Wi-Fi connection activates.
In nm-connection-editor this is called:
"Automatically connect to VPN when using this connection".
> Personally I consider this as a bug:
> - If the autoconnect flag is available for VPN connections, NM should
> not ignore it.
Yeah, it's a bug/missing feature.
> - With NM 0.9 it just worked for all types of devices.
I don't think that changed.
> - Different behavior for different devices is inconsistent.
Yes, that would be bad, but I am not sure there is a difference here.
> What do you think; is it a bug or the expected bahavior?
> Are you interested in log files (e.g. one capturing booting with
> Ethernet enabled and one capturing booting with GSM enabled)?
Before activating the VPN connection, you should ensure that you
activate another connection (ethernet, Wi-Fi, GSM) to give you internet
connectivity. That other connection can be configured to "autoconnect"
as you like.
Good luck,
Thomas
>
> Thank you and regards,
> Adrian
>
>
> On Mon, 2016-02-01 at 13:34 -0600, Dan Williams wrote:
> > On Fri, 2016-01-29 at 23:44 +0100, Adrian Freihofer wrote:
> > > Hi Thomas
> > >
> > > Thank you for taking care about this issue.
> > > With my current setup I'm able to reproduce this. Unfortunately I
> > > cannot use NetworkManager 1.2. I'm working on a cross compiled
> > > Embedded System (based on Yocto). I guess NM 1.2 has been ported
> > > to
> > > GObject, which cannot be cross compiled by design.
> > > Yocto next will provide a solution based on Qemu. But my project
> > > is
> > > not in a phase where I can upgrade the OS to current unstable
> > > branch
> > > right now. Are you able to reproduce and test this?
> > > I found a workaround to relax the situation for my use case: If
> > > the
> > > interfaces are enabled exclusively NM works more stable. Given
> > > this
> > > patch cannot be back ported this is OK for me now.
> > >
> > >
> > > There is another finding related to the the same use case and
> > > setup.
> > > I have a VPN connection configured with autoconnect=true.
> > > As a physical connection there are three different types
> > > available:
> > > Ethernet, WLAN and Mobile. Due to the problem you hopefully
> > > solved
> > > now,
> > > they are enabled only exclusively now. With Ethernet and WLAN NM
> > > works
> > > perfect: After the physical connection has established, NM
> > > immediately
> > > setup the VPN connection. With Mobile connection VPN is not
> > > automatically
> > > established by NM. Only a manual trigger gets the VPN connection
> > > establishing.
> > > With latest 0.9 version of NM this worked great. With 1.0.10 it
> > > does
> > > not.
> > > Also rebooting the system behaves similar. The Mobile connection
> > > is
> > > established but not the VPN.
> >
> > Debug logs from this last case (WWAN+VPN) would be nice to have
> > here.
> >
> > And just to be sure, you have the VPN connection set as a
> > "secondary"
> > on the WWAN connection, right? VPNs don't actually autoconnect,
> > they
> > are trigged by a parent connection when the parent is finished
> > activating.
> >
> > Dan
> >
> > > May be you have an idea how to solve this too?
> > >
> > >
> > > Regards,
> > > Adrian
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 2016-01-29 at 17:32 +0100, Thomas Haller wrote:
> > > > On Fri, 2016-01-22 at 14:48 +0100, Adrian Freihofer wrote:
> > > > > Hi,
> > > > >
> > > > > Setup an OpenVPN connection with NetworkManager 1.0.10 is not
> > > > > always painless... I ended up with a setup where an
> > > > > infinite number of openvpn daemons tried to connect to one
> > > > > single
> > > > > server.
> > > > > The problem seems to be that NetworkManager does not (or at
> > > > > least
> > > > > not
> > > > > in any case) stop a VPN connection (stop the
> > > > > openvpn daemon) to a particular remote before setting up a
> > > > > new
> > > > > VPN
> > > > > connection (start an openvpn daemon) to the same
> > > > > remote.
> > > >
> > > >
> > > > It seems the the pending child processes in nm-openvpn-service
> > > > are
> > > > not
> > > > properly tracked.
> > > >
> > > > I opened BZ https://bugzilla.gnome.org/show_bug.cgi?id=761299 f
> > > > or
> > > > that
> > > > and patch
> > > > https://git.gnome.org/browse/network-manager-openvpn/log/?h=th/
> > > > hand
> > > > le
> > > > -child-process-bgo761299
> > > > is on review. ...
> > > >
> > > > Thought his patch will not trivially backport to nm-1-0
> > > > branch...
> > > >
> > > >
> > > >
> > > > Thomas
> > > _______________________________________________
> > > networkmanager-list mailing list
> > > [email protected]
> > > https://mail.gnome.org/mailman/listinfo/networkmanager-list
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
