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. DanMay 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 networkmanager-list gnome org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Attachment:
signature.asc
Description: This is a digitally signed message part