I've just updated and have the new version of this package. Unfortunately, it now fails immediately every time. I've even deleted and recreated the vpn connection profile. Often, it leaves /usr/lib/network-manager-openvpn/nm-openvpn-service running in the background consuming all of the CPU.
Here's syslog output:
Oct 2 07:34:48 localhost nm-openvpn[1347]: LZO compression initialized
Oct 2 07:34:48 localhost nm-openvpn[1347]: UDPv4 link local: [undef]
Oct 2 07:34:48 localhost nm-openvpn[1347]: UDPv4 link remote: xx.xx.xx.xx:1194
Oct 2 07:34:49 localhost nm-openvpn[1347]: [xxx.xxx.org] Peer Connection Initiated with xx.xx.xx.xx:1194
Oct 2 07:34:50 localhost nm-openvpn[1347]: TUN/TAP device tun0 opened
Oct 2 07:34:50 localhost nm-openvpn[1347]: ifconfig tun0 10.xx.xx.x pointopoint 10.xx.xx.y mtu 1500
Oct 2 07:34:50 localhost kernel: [ 655.448000] tun0: Disabled Privacy Extensions
Oct 2 07:34:50 localhost nm-openvpn[1347]: /usr/lib/network-manager-openvpn/nm-openvpn-service-openvpn-helper tun0 1500 1542 10.xx.xx.x 10.xx.xx.y init
Oct 2 07:34:50 localhost nm-openvpn[1347]: script failed: shell command exited with error status: 139
Oct 2 07:34:50 localhost nm-openvpn[1347]: Exiting
Oct 2 07:34:50 localhost NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.openvpn', signal 'ConnectFailed', with message 'The VPN login failed because the VPN program could not connect to the VPN server.'.
Oct 2 07:34:50 localhost NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 3 -> 6.
Oct 2 07:34:50 localhost NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.openvpn): could not stop connection 'xxxxxx' because service was 6.
When I connect from the command line, it connects right up.
Also, regarding the timeout patch, wouldn't it be preferable to have this be a user-configurable option. for some people 5s may be sufficient, while others may need 20-25s if the connection is really slow or saturated.
Hi,
Thanks for the attention to this bug.
I've just updated and have the new version of this package. Unfortunately, it now fails immediately every time. I've even deleted and recreated the vpn connection profile. Often, it leaves /usr/lib/ network- manager- openvpn/ nm-openvpn- service running in the background consuming all of the CPU.
Here's syslog output: network- manager- openvpn/ nm-openvpn- service- openvpn- helper tun0 1500 1542 10.xx.xx.x 10.xx.xx.y init service_ process_ signal( ): VPN failed for service 'org.freedeskto p.NetworkManage r.openvpn' , signal 'ConnectFailed', with message 'The VPN login failed because the VPN program could not connect to the VPN server.'. p.NetworkManage r.openvpn' signaled state change 3 -> 6. service_ stop_connection (): (VPN Service org.freedesktop .NetworkManager .openvpn) : could not stop connection 'xxxxxx' because service was 6.
Oct 2 07:34:48 localhost nm-openvpn[1347]: LZO compression initialized
Oct 2 07:34:48 localhost nm-openvpn[1347]: UDPv4 link local: [undef]
Oct 2 07:34:48 localhost nm-openvpn[1347]: UDPv4 link remote: xx.xx.xx.xx:1194
Oct 2 07:34:49 localhost nm-openvpn[1347]: [xxx.xxx.org] Peer Connection Initiated with xx.xx.xx.xx:1194
Oct 2 07:34:50 localhost nm-openvpn[1347]: TUN/TAP device tun0 opened
Oct 2 07:34:50 localhost nm-openvpn[1347]: ifconfig tun0 10.xx.xx.x pointopoint 10.xx.xx.y mtu 1500
Oct 2 07:34:50 localhost kernel: [ 655.448000] tun0: Disabled Privacy Extensions
Oct 2 07:34:50 localhost nm-openvpn[1347]: /usr/lib/
Oct 2 07:34:50 localhost nm-openvpn[1347]: script failed: shell command exited with error status: 139
Oct 2 07:34:50 localhost nm-openvpn[1347]: Exiting
Oct 2 07:34:50 localhost NetworkManager: <WARN> nm_vpn_
Oct 2 07:34:50 localhost NetworkManager: <info> VPN service 'org.freedeskto
Oct 2 07:34:50 localhost NetworkManager: <WARN> nm_vpn_
When I connect from the command line, it connects right up.
Also, regarding the timeout patch, wouldn't it be preferable to have this be a user-configurable option. for some people 5s may be sufficient, while others may need 20-25s if the connection is really slow or saturated.