Management interface crashes with --tun-ipv6 on Windows

[dbernt]

Failed assertion when using the management interface on Windows clients with --tun-ipv6 on:

[...]
Tue Aug 26 13:31:49 2014 Initialization Sequence Completed
Tue Aug 26 13:31:50 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:7505
Tue Aug 26 13:31:50 2014 MANAGEMENT: CMD 'state'
Tue Aug 26 13:31:50 2014 MANAGEMENT: Client disconnected
Tue Aug 26 13:31:50 2014 MANAGEMENT: TCP recv error: An operation was attempted on something that is not a socket.
Tue Aug 26 13:31:50 2014 Assertion failed at win32.c:278
Tue Aug 26 13:31:50 2014 Exiting due to fatal error
[...]

This happens on several Windows 7 and Windows XP systems. After "Initialization Sequence Completed" I connect to the management interface, run "state", and disconnect once every second. Usually this happens the first time but not always. Sometimes it takes a minute or a half of connecting every second and sometimes it can run for at least about an hour with no problem. The same thing happens with the "signal" command. This only happens with --tun-ipv6.

I guess man->connection.ne32->sd is sometimes not reset when reused for a new connection but have no idea why.

Using openvpn downloaded from openvpn.net:

openvpn.exe --version
OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6
] built on Apr 8 2014
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>
Compile time defines: enable_crypto=yes enable_debug=no enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=needless enable_fragment=yes enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=yes enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_special_build= with_sysroot=no

[Gert Döring]

Interesting bug, looks like a race condition - management interface isn't really intended to be reconnected and disconnected every second.

I'm not sure why it would be related to --tun-ipv6 - that should not have *any* effect on the management interface or the socket handling at all (it's just "inside the tunnel") - maybe it changes the amount of data printed in response to "state" and that changes the propability for the race condition...

We'll accept this as a bug, but it won't be worked upon with high priority - it's an edge case, and we're currently trying to focus on getting 2.4 ready (which might not even have that issue, as quite a bit of socket handling was rewritten), and we already have not enough development power for the "main cases" that need to be handled - sorry.

[dbernt]

Sure, I can just reuse the same connection and never close it. I realise now that I have not been running the "exit" command before closing the connection. Maybe that is necessary? So far that seems to work.

[Gert Döring]

We've not actually looked into this in the past 8 years (sorry for that) but we did have a number of socket handling rewrites - and tun-ipv6 is now always-on. So I blatantly claim we might have fixed it, accidentially.

If not, please reopen.