Hi Dan
This is my VPN connection configuration:
settings = {u'connection': {u'type': u'vpn',
u'autoconnect': True,
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.
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?
Personally I consider this as a bug:
- If the autoconnect flag is available for VPN connections, NM should not
ignore it.
- With NM 0.9 it just worked for all types of devices.
- Different behavior for different devices is inconsistent.
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)?
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 for
> > > 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
_______________________________________________
networkmanager-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/networkmanager-list
