[Openvpn-users] Windows: on the suspend/resume bug

[Selva N. <sel...@gm...>]

Hi,

After an update of the tap driver to NDIS6 (tap-windows6) on a windows
7 client, now I too see what many others have been reporting as the
suspend/resume bug.

Basically, openvpn.exe terminates when windows suspends (put to
sleep). On resume the process is gone.

The chain of events go like this: the new NDIS6 TAP driver halts on
windows suspend --- I think it should not, but it does. This sets
ERROR_OPERATION_ABORTED (code=995) on further reads from the tun.
Recent versions of openvpn (around 2.3.6 and newer?) terminates in
this condition -- as enforced by commit
7aa178381241ae015273914065471e0d271ee1c3

The code=995 error appears to be generated during catastrophic events
like surprise removal of the adapter, when the adapter is disabled,
when tapinstall.exe (addtap.bat) causes a reset of the driver etc., as
well as during well-managed power state changes like suspend. Older
versions of openvpn that ignored this error get trapped in a read
error cycle trashing the CPU and the log.

But I don't think its necessary (nor appropriate when its triggered by
suspend) to signal SIGTERM to handle this. A restart by SIGHUP is
enough. If its triggered by suspend, the restart will succeed on
resume. If the adapter really disappeared, the restart will fail with
a SIGTERM at a later point. That would offer a much better user
experience. I tried this and it seems to work well  -- those who want
to test this may find the diff below (against git-master) useful.

Some of the above comments are based on guesswork as I don't have a
tap6 driver built with --debug. If anyone has one please share the
driver.

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 62eb6fc..cef063d 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -958,8 +958,9 @@ read_incoming_tun (struct context *c)
   /* Was TUN/TAP I/O operation aborted? */
   if (tuntap_abort(c->c2.buf.len))
   {
-     register_signal(c, SIGTERM, "tun-abort");
-     msg(M_FATAL, "TUN/TAP I/O operation aborted, exiting");
+     register_signal(c, SIGHUP, "tun-abort");
+     c->persist.restart_sleep_seconds = 10;
+     msg(M_INFO, "TUN/TAP I/O operation aborted, restarting");
      perf_pop();
      return;
   }

This gracefully handles TAP reset when a new adapter is added using
addtap.bat or a quick disable/enable of the adapter, in addition to
handling suspend/resume without a termination. If the adapter truly
disappears, openvpn will terminate during the restart.

A note on the GUI: the GUI distributed with latest windows installer
listens for the suspend event (PBT_APMSUSPEND), terminates openvpn and
restarts it on resume.  While this may nicely hide the suspend/resume
issue, the GUI should not be second guessing what openvpn should do on
suspend. This behaviour can be changed by setting the registry key
"disconnect_on_suspend=0". I suggest to make this the default. If you
replace the SIGTERM by SIGHUP as suggested above, this change is
necessary for the GUI to operate as expected.

Management interface based UI's should work well with this change..

Selva

P.S. forward.c has another situation where SIGTERM is sent when read
from tun sets ERROR_FILE_NOT_FOUND. This could also be made into a
SIGHUP letting the restart fail later if the device has truly
disappeared.