Re: networkmanager starts infinite number of VPN daemons

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,

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
they are enabled only exclusively now. With Ethernet and WLAN NM
perfect: After the physical connection has established, NM
setup the VPN connection. With Mobile connection VPN is not
established by NM. Only a manual trigger gets the VPN connection
With latest 0.9 version of NM this worked great. With 1.0.10 it does
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


May be you have an idea how to solve this too?


On Fri, 2016-01-29 at 17:32 +0100, Thomas Haller wrote:
On Fri, 2016-01-22 at 14:48 +0100, Adrian Freihofer wrote:

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
The problem seems to be that NetworkManager does not (or at least
in any case) stop a VPN connection (stop the
openvpn daemon) to a particular remote before setting up a new
connection (start an openvpn daemon) to the same

It seems the the pending child processes in nm-openvpn-service are
properly tracked.

I opened BZ for
and patch
is on review. ...

Thought his patch will not trivially backport to nm-1-0 branch...

networkmanager-list mailing list
networkmanager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]