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 > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
