Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#88 closed Bug / Defect (notabug)

management-forget-disconnect crashes process

Reported by: bwess Owned by: David Sommerseth
Priority: minor Milestone:
Component: Management Version: OpenVPN 2.1.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


Verified on the Windows version of openvpn.
Easy to test since openvpn is on hold.

  1. Add the following options to a client config file:

management 1194
auth-retry interact

  1. Start openvpn as a service.
  2. Connect to the management interface (telnet 1194).
  3. Disconnect from the management interface (exit).
  4. That openvpn process crashes reliably, but only if management-forget-disconnect is used.

Change History (8)

comment:1 Changed 12 years ago by David Sommerseth

Are you able to test this config on a Linux or *BSD box as well? That could help narrow it down to if it is a Windows only or a more generic bug.

I tried using exactly the same options you used on Fedora 14 with openvpn 'allmerged' (based on commit c0f8e9f19842), and it doesn't crash at all for me.

comment:2 Changed 12 years ago by bwess

I did a quick test with "OpenVPN 2.1.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Jul 5 2010" included in openSUSE 11.3, it also happens:

Feb 22 17:34:07 hostname kernel: [26618.966184] openvpn[7008]: segfault at 10 ip 00007f46a552cf05 sp 00007fffc30f3b10 error 4 in[7f46a551f000+1a000]

comment:3 Changed 12 years ago by David Sommerseth

Hmmm ... Would it be possible to get a complete configuration files, at least for the client. Server would also help to try to reproduce this issue.

I just tried openvpn-2.1.1 on Fedora 14, and again, no issues.

Tue Feb 22 18:10:28 2011 OpenVPN 2.1.1 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Jan 5 2010

comment:4 Changed 12 years ago by David Sommerseth

If I had opened my eyes a little bit more ... I would have noticed that your crash refers to

Still it would be useful to see config files. Another thing, can you please start your openvpn session via gdb and take out a backtrace? See for more info. That can help more to figure out if this is an OpenVPN problem or a libpkcs11 issue. If doable, please consider to enable core dump files and send it to us. You can send it to me directly, to preserve your privacy (dazo{a}

comment:5 Changed 12 years ago by David Sommerseth

Owner: set to David Sommerseth
Status: newaccepted

An update!

I've managed to reproduce it with Jan Just Keijser's help. It is related to the pkcs11-helper library. My error was that I did 'hold release' before exiting. But by not doing 'hold release' and just do 'exit' directly, then it does crash *if* the PKCS#11 feature is enabled in OpenVPN.

This issue has been reported to the OpenSC developers.

What OpenVPN does is to call pkcs11h_logout() before the pkcs11 environment have been initialised correctly in this situation. Which is comparable to doing this:

#include <pkcs11-helper-1.0/pkcs11h-openssl.h>

int main() {
          return 0;

And this gives the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000036a300ca45 in pkcs11h_logout () at pkcs11h-core.c:1069
1069			current_session = _g_pkcs11h_data->sessions;
Missing separate debuginfos, use: debuginfo-install zlib-1.2.5-2.fc14.x86_64
(gdb) bt
#0  0x00000036a300ca45 in pkcs11h_logout () at pkcs11h-core.c:1069
#1  0x000000000040060d in main ()

When this error happens in OpenVPN, the backtrace looks like this:

#0  0x00000036a300ca45 in pkcs11h_logout () at pkcs11h-core.c:1069
#1  0x000000000042f049 in pkcs11_logout () at pkcs11.c:385
#2  0x000000000045112b in ssl_purge_auth () at ssl.c:320
#3  0x000000000041c6f5 in man_reset_client_socket (man=0x8a1800, exiting=0) at manage.c:1560
#4  0x000000000041efda in man_read (man=0x8a1800) at manage.c:1717
#5  management_io (man=0x8a1800) at manage.c:2414
#6  0x000000000041f0f3 in man_standalone_event_loop (man=0x8a1800, signal_received=0x7fffffffd7ec, expire=<value optimized out>)
    at manage.c:2518
#7  0x000000000041f33d in management_hold (man=0x8a1800) at manage.c:2744
#8  0x0000000000414ea6 in do_hold (c=0x7fffffffd870) at init.c:1405
#9  0x00000000004151ad in open_management (c=0x7fffffffd870) at init.c:2753
#10 0x000000000042fc1a in main (argc=5, argv=0x7fffffffe628) at openvpn.c:193

I'll look more carefully into the OpenVPN code to see if there is a way how to avoid this situation in OpenVPN too. But the core issue is in the pkcs11-helper library, in my opinion.

comment:6 Changed 12 years ago by David Sommerseth

Resolution: notabug
Status: acceptedclosed

Things happens quickly today ...

As this is now confirmed as a pkcs11-helper bug, I'm closing this ticket as "notabug", as it is not an issue in OpenVPN.

comment:7 Changed 12 years ago by Samuli Seppänen

Latest preview of OpenVPN 2.2-rc contains a fixed version of pkcs11-helper. Could you verify that it fixes this issue?

comment:8 Changed 12 years ago by bwess

Tested with
"OpenVPN 2.2-RC Win32-MSVC++ [SSL] [LZO2] built on Feb 28 2011"
and verified that the problem does *not* occur anymore.

Note: See TracTickets for help on using tickets.