timing problem

[Vincenzo Ampolo]

Binary package hint: network-manager-openvpn

When i try to connect, the applet sends a "disconnect" command to the server while the server is checking the key.
This will abort the connection just because the applet does not wait more until the server answer.
This problem depends from server loads (this is logic, if the server is busy, the answer will take more time and the applet doesn't wait the server answer)

Using openvpn from terminal the connection works

[Zach (uid000)]

I can confirm this. For me, over slow connections the openvpn plugin gives up too quickly. using openvpn from the commandline can take 20 seconds if the connection is particularly slow or saturated. The plugin usually gives up after around 5 seconds.

The openvpn plugin should have a longer timeout, or the timeout should be configurable.

[Philipp Kern (pkern)]

In fact the plugin also retries openvpn as often as possible during the interval.

[Philipp Kern (pkern)]

A new version of network-manager-openvpn was uploaded to fix this bug.

To review the current version, please run

  dget -x http://ppa.launchpad.net/pkern/ubuntu/pool/main/n/network-manager-openvpn/network-manager-openvpn_0.3.2svn2342-1ubuntu3.dsc

[Philipp Kern (pkern)]

network-manager-openvpn (0.3.2svn2342-1ubuntu3) gutsy; urgency=low

  [ Cleanup ]
  * Switched to quilt for patch management.
  * Properly activated the awk patch.

  [ Bug fixes ]
  * Increased the timeout by 5s to 15s before openvpn gets killed
    forcefully. (LP: #117992)
  * Corrected the path to `nm-vpn-properties' in the desktop file.
    (LP: #123772)
  * Pull DNS domain setting from remote OpenVPN server.
    (LP: #138181)
  * Introduced a new configuration option enabling users to turn off the
    check for a proper `nsCertType=server' extension bit set in the
    server's certificate. (LP: #94788)

  [ Philipp Kern ]
  * Fixes (LP: #145884)

 -- Philipp Kern <email address hidden> Fri, 28 Sep 2007 02:05:51 +0200

[Zach (uid000)]

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:
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.

[Philipp Kern (pkern)]

It would be preferable indeed, I currently integrated a compromise. People, please don't upgrade currently. Please see #147941 for it and help debugging this problem as I cannot reproduce it.

[Philipp Kern (pkern)]

Well I increased the timeout because the default one was really too low. Please open a new (wishlist) bug about this feature request.

[Zach (uid000)]

It's working fine for now. I appreciate your attention to this matter, as well as for #147941. Everything is working great now.

[Edouard Lafargue (edouard-lafargue)]

I have experienced the same issues: OpenVPN connection timeouts should be configurable, or set to a much higher value: typically, over a GSM/GPRS connection, a 40/60 second timeout is not unreasonable, since this type of connection has very high latency times...

[Leonid Evdokimov (darkk)]

I've spent half an hour debugging same problem and I vote for 60seconds timeout as my server logs show following:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

where 60 equals handshake_window from openvpn-2.0.7 soruces.
60 seconds is default openvpn setting and I assume that network-manager-openvpn should use it.