Santtu Lakkala [Mon, 21 Oct 2019 11:35:06 +0000 (14:35 +0300)]
Fix OpenSSL private key passphrase notices
Clear error stack on successful certificate loading in
tls_ctx_load_cert_file_and_copy() and handle errors also for
PEM_read_bio_PrivateKey() call in tls_ctx_load_priv_file().
Due to certificate loading possibly leaking non-fatal errors on OpenSSL
error stack, and some slight oversights in error handling, the
>PASSWORD:Verification Failed: 'Private Key'
line was never produced on the management channel for PEM formatted keys.
Ilya Shipitsin [Sun, 22 Mar 2020 12:35:21 +0000 (17:35 +0500)]
travis-ci: add arm64, s390x builds.
as described on https://docs.travis-ci.com/user/multi-cpu-architectures
travis-ci
now supports amd64, ppcle, arm64, s390 architectures. Add arm64 and s390x.
travis-ci images were upgraded to bionic.
"sudo" is deprecated, let us remove it, also "matrix" is deprecated in
favour of "jobs".
LD_LIBRARY_PATH was replaced by using "rpath" in LDFLAGS, which is more
elegant way of linking.
also, dependencies were upgraded to the latest versions.
travis_wait was added for long openssl builds.
cmocka was added to linux and osx builds. Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200322123521.17710-1-chipitsine@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19574.html
Simon Rozman [Mon, 9 Mar 2020 13:17:26 +0000 (14:17 +0100)]
openvpnmsica, tapctl: Revise default hardware ID management
tap_create_adapter() and tap_list_adapter() no longer default to
"root\tap0901". Defining a default hardware ID value is at the
responsibility of upper layers that process user desires.
Since the tap_list_adapter() no longer defaults the hardware ID to
anything, its behavior was simplified to return all existing
adapters when a NULL hardware ID is specified.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200309131728.380-10-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19524.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Mon, 9 Mar 2020 13:17:24 +0000 (14:17 +0100)]
openvpnmsica: "TAP" => "TUN/TAP"
The function and property names that are common to TAP and TUN from
TAP-Windows6 and TUN from Wintun were renamed not to make the now
mainstream TUN sad.
I would have go with just the "adapter". But, wouldn't that cause
confusion when user sees "Deleting adapters" when uninstalling the
OpenVPN?
Internal variable names were simplified thou to omit the TUN/TAP
referencing.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200309131728.380-8-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19526.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Mon, 9 Mar 2020 13:17:23 +0000 (14:17 +0100)]
openvpnmsica, tapctl: "interface" => "adapter"
Interface is not equal to adapter. A quote from Microsoft documentation:
> There is a one-to-one correspondence between the interfaces and
> adapters on a given computer. An interface is an IP-level abstraction,
> whereas an adapter is a datalink-level abstraction.
As tapctl and openvpnmsica are all about managing network adapters on
Windows computers, the terminology has been updated.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200309131728.380-7-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19529.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Tue, 10 Mar 2020 09:48:21 +0000 (10:48 +0100)]
tun.c: reorder IPv6 ifconfig on Windows
The IPv6 interface network route should be setup as soon as possible
after the interface address is set. Actually, all routes should be added
before DNS servers are configured. This would allow Windows to validate
DNS servers properly instead of shutting the validation off.
The cleanup order has been changed to match reverse order of ifconfig.
An additional check was added to skip the cleanup when --ip-win32 is set
to manual.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200310094822.588-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19541.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Thu, 12 Mar 2020 06:08:29 +0000 (08:08 +0200)]
tun.c: fix 'use after free' error
Commit 509c45f has factored out code blocks of open_tun()
into separate functions and introduced "use after free" bug:
Variable "device_guid" is allocated inside tun_open_device()
function and used outside of it. Allocation happens with
local gc_arena, which is freed at the end of tun_open_device(),
making futher access to "device_guid" invalid.
Fix by ensuring that gc_arena scope covers all access to "device_guid".
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Simon Rozman <simon@rozman.si>
Message-Id: <20200312060829.19468-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19547.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Domagoj Pensa [Wed, 5 Feb 2020 12:46:14 +0000 (13:46 +0100)]
Skip DNS address validation
When adding IPv4 DNS servers without interactive service use
"validate=no", on Windows 7 and higher, to skip time consuming automatic
address validation, that is on by default.
Simon Rozman [Wed, 5 Feb 2020 18:38:41 +0000 (19:38 +0100)]
wintun: upgrade error message in case of ring registration failure
Rather than have the Interactive Service return a custom 0x20000004
(ERROR_REGISTER_RING_BUFFERS) error, return the true GetLastError() code
that the TUN_IOCTL_REGISTER_RINGS provides.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200205183841.1118-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19367.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Mon, 9 Mar 2020 13:17:17 +0000 (14:17 +0100)]
openvpnmsica: Remove required Windows driver certification detection
The MSI packages are switching to TAP-Windows6 and Wintun MSM modules to
install the TAP/TUN driver. The MSM modules have built-in Windows
version detection already.
This commit is now-dead-code clean up with uncrustification.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200309131728.380-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19530.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Fri, 21 Feb 2020 10:07:46 +0000 (11:07 +0100)]
Move NCP related function into a seperate file and add unit tests
This allows unit test the NCP functions. The ssl.c file has too
many dependencies to make unit testing of it viable.
Patch V2: Removing the include "ssl_ncp.h" from options.c for V2 of
implement dynamic NCP forces a new version of this patch to
add the #include in this patch. Merge VS studio file changes
for ssl_ncp.[ch] into this patch
Patch V3: Regenerate for changes in earlier patches, apply Lev's changes
to Visual Studio project file
Patch V4: Regenerate to also have the changes of earlier patches.
Patch V5: Fix unit tests for crypto library missing chacha20-poly1305
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Lev Stipakov <lstipakov@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200221100746.7065-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19499.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Selva Nair [Thu, 20 Feb 2020 01:56:43 +0000 (20:56 -0500)]
Fix possible access of uninitialized pipe handles
Compile time warning for openvpnserv.exe
interactive.c: In function ‘RunOpenvpn’:
interactive.c:160:27: warning: ‘svc_pipe’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
When RunOpenvpn exits early due to errors, uninitialized svc_pipe and
ovpn_pipe vars could get passed to CloseHandleEx(). Fix by initializing
to NULL.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1582163803-3342-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19480.html Signed-off-by: David Sommerseth <davids@openvpn.net>
Arne Schwabe [Wed, 19 Feb 2020 11:21:53 +0000 (12:21 +0100)]
Warn about insecure ciphers also in init_key_type
With modern Clients and server initialising the crypto cipher later
and not when reading in the config, most users never the warning when
having selected BF-CBC in the configuration.
This patch adds the logic to print out warning to init_key_type.
Main reason for this patch is a personal experience with someone who was
strictly against putting 'cipher' into a config file because he did not
like hardcoding a cipher and "OpenVPN will do AES-GCM anyway" and thinks
that it is better to not have it in configuration even after told by me
that 15 year defaults might not be good anymore.
Patch V2: rebase on master, fix minor style issues
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Steffan Karger <steffan.karger@foxcrypto.com>
Message-Id: <20200219112153.13013-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19476.html Signed-off-by: David Sommerseth <davids@openvpn.net>
Documented all the argv related code with minor refactoring
Added doxygen comments for all the functions in argv.c.
There are some slight refactoring, renaming a few variables to make
their use case more obvious and ensure lines do not break our 80-chars
per line coding style limit.
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200206132103.15977-5-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19377.html
Heiko Hund [Thu, 6 Feb 2020 13:21:02 +0000 (14:21 +0100)]
Add gc_arena to struct argv to save allocations
With the private gc_arena we do not have to allocate the strings
found during parsing again, since we know the arena they are
allocated in is valid as long as the argv vector is.
Signed-off-by: Heiko Hund <heiko.hund@sophos.com> Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200206132103.15977-4-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19376.html
Heiko Hund [Thu, 6 Feb 2020 13:21:01 +0000 (14:21 +0100)]
argv: do fewer memory re-allocations
Prevent the re-allocations of memory when the internal argv grows
beyond 2 and 4 arguments by initially allocating argv to hold up to
7 (+ trailing NULL) pointers.
While at it rename argv_reset to argv_free to actually express
what's going on. Redo the argv_reset functionality so that it can
be used to actually reset the argv without re-allocation.
Signed-off-by: Heiko Hund <heiko.hund@sophos.com> Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200206132103.15977-3-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19378.html
Heiko Hund [Thu, 6 Feb 2020 13:21:00 +0000 (14:21 +0100)]
re-implement argv_printf_*()
The previous implementation had the problem that it was not fully
compatible with printf() and could only detect % format directives
following a space character (0x20).
It modifies the format string and inserts marks to separate groups
before passing it to the regular printf in libc. The marks are
later used to separate the output string into individual command
line arguments.
The choice of 0x1D as the argument delimiter is based on the
assumption that no "regular" string passed to argv_printf_*() will
ever have to contain that byte (and the fact that it actually is
the ASCII "group separator" control character, which fits its
purpose).
This commit has been updated by David Sommerseth based on Arne
Schwabe and his own feedback on the mailing list.
Signed-off-by: Heiko Hund <heiko.hund@sophos.com> Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200206132103.15977-2-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19380.html
Arne Schwabe [Mon, 17 Feb 2020 14:43:37 +0000 (15:43 +0100)]
Implement dynamic NCP negotiation
Our current NCP version is flawed in the way that it can only indicate
support for AES-256-GCM and AES-128-GCM. While configuring client and
server with different ncp-cipher configuration directive works, the
server will blindly push the first cipher of that list to the client
if the client sends IV_NCP=2.
This patches introduces IV_CIPHER sent from the client to the server that
contains the full list of ciphers that the client is willing to support (*).
The server will then pick the first cipher of its own ncp-cipher list that
the client indicates support for.
We choose a textual representation of the ciphers instead of a binary since
a binary would mean that we would need to have a central place to maintain
a mapping between binary and the actual cipher name. Also the normal
ncp-cipher list is quite short, so this should not be problem. It also
provides the freedom to negioate new ciphers from SSL libraries without
the need to upgrade OpenVPN/its binary cipher table.
* the client/server will also accpt the cipher specified in --cipher
but eventually we want to get rid of --ciper. So this patch keeps a
reasonable backwards compatbility (especially poor man's NCP) but does
not encourage to use --cipher for negotiation in documentation or
warning messages.
Patch V2: Remove #include "ssl_ncp.h" Note to compile on windows the patch
"Add strsep compat function" should be applied first
Patch V3: Use string_alloc with gc instead strdup()
Patch V4: Integrate using a short lived gc from patch 006 directly
into this patch
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200217144339.3273-4-arne@rfc2549.org>
URL: https://www.mail-archive.com/search?l=mid&q=20200217144339.3273-4-arne@rfc2549.org Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Mon, 17 Feb 2020 14:43:35 +0000 (15:43 +0100)]
Only announce IV_NCP=2 when we are willing to support these ciphers
We currently always announce IV_NCP=2 when we support these ciphers even
when we do not accept them. This lead to a server pushing a AES-GCM-128
cipher to clients and the client then rejecting it.
Patch V2: Remove unecessary restoring of ncp_ciphers
Patch V3: Do not add ncp_ciphers in context
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200217144339.3273-2-arne@rfc2549.org>
URL: https://www.mail-archive.com/search?l=mid&q=20200217144339.3273-2-arne@rfc2549.org Signed-off-by: Gert Doering <gert@greenie.muc.de>
Selva Nair [Wed, 12 Feb 2020 15:06:07 +0000 (10:06 -0500)]
Allow unicode search string in --cryptoapicert option
Currently when the certificate is specified as "SUBJ:foo", the
string foo is assumed to be ascii. Change that and interpret
it as utf-8, convert to a wide string, and flag it as unicode
in CertFindCertifcateInStore().
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581519967-16950-2-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19405.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Selva Nair [Wed, 12 Feb 2020 15:06:06 +0000 (10:06 -0500)]
Skip expired certificates in Windows certificate store
Have the cryptoapicert option find the first matching certificate
in store that is valid at the present time. Currently the first
found item, even if expired, is returned.
This makes it possible to update certifiates in store without having
to delete old ones. As a side effect, if only expired certificates are
found, the connection fails.
Also remove some unnecessary casts.
Tested on Windows 10.
Trac #966
v4: Handle the case when an unknown certificate specification is passed
to find_certificate_in_store().
Note: Warnings printed from find_certificate_in_store() could show up
multiple times as its called for each certificate store. This could
be improved in a future patch.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581519967-16950-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19404.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Tue, 21 Jan 2020 08:08:28 +0000 (10:08 +0200)]
configure.ac: simplify AC_CHECK_FUNCS statements
AC_CHECK_FUNCS checks availability of each function
in argument list and defines HAVE_function macro.
AC_CHECK_FUNC takes single function as an argument and
doesn't automatically define any macros.
When we check for availability of a single function and
define own macro, it is enough to use AC_CHECK_FUNC.
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200121080828.1310-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19333.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Selva Nair [Mon, 10 Feb 2020 04:33:20 +0000 (23:33 -0500)]
Swap the order of checks for validating interactive service user
Check the config file location and command line options first
and membership in OpenVPNAdministrators group after that as
the latter could be a slow process for active directory users.
When connection to domain controllers is poor or unavailable, checking
the group membership is slow and causes timeouts in the GUI (Trac
1051). However, in cases where the config is in the global directory,
no group membership check should be required. The re-ordering here
avoids the redundant check in such cases.
In addition to this, its also proposed to improve the timeout handling
in the GUI, but this change is still useful as it should completely
eliminate the timeout issue for many users.
v3: Do not send error message to the client pipe from ValidateOptions().
Instead save the error and send it on only if user authorization also
fails. The error buffer size is increased to 512 wide chars as these
messages could get long in some cases and may get truncated otherwise.
Also see: https://github.com/OpenVPN/openvpn-gui/issues/332
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581309200-27870-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19388.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Domagoj Pensa [Wed, 5 Feb 2020 12:46:15 +0000 (13:46 +0100)]
Fix linking issues on MinGW
MinGW linking fails for several files if compiled without "-O2" due to
a missing "static" declaration for inline functions tuntap_is_wintun()
and tuntap_ring_empty().
Signed-off-by: Domagoj Pensa <domagoj@pensa.hr> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200205124615.15758-3-domagoj@pensa.hr>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19356.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Steffan Karger [Mon, 20 Jan 2020 11:55:18 +0000 (12:55 +0100)]
Move keying material exporter check from syshead.h to configure.ac
Commit ab27c9f7 added a compile-time check for availablitity of
keying-material-export functionality to syshead.h. It turns out that
openvpnserv also includes syshead.h, and has ENABLE_CRYPTO_* defined in
it's config.h, but doesn't have the necessary CFLAGS / LIBS to actually
compile and link against the crypto libraries. That of course breaks
openvpnserv builds.
To fix this, change the compile-time check in syshead.h into a
configure-time check in configure.ac. That's more consistent with how we
do other feature checks anyway.
Signed-off-by: Steffan Karger <steffan.karger@foxcrypto.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <E1itVts-0007ZG-NO@sfs-ml-2.v29.lw.sourceforge.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19328.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Steffan Karger [Sun, 10 Nov 2019 23:10:18 +0000 (00:10 +0100)]
mbedtls: add RFC 5705 keying material exporter support
Since mbed TLS 2.18, mbed TLS can also implement RFC 5705. As a first
step towards using the keying material exporter as a method to generate
key material for the data channel, implement the
--keying-material-exporter function we already have for OpenSSL also for
mbed TLS builds.
Implementing RFC 5705 for mbed TLS is a bit more cumbersome, because the
library itself only provides a callback that is called during connection
setup, which enables us to implement RFC 5705 ourselves. To protect
ourselves against mistakes, we immediately perform the required key
derivation to generate the exporterd keying material, and only cache the
derived key material until we can actually export it to the environment
(similar to the OpenSSL builds).
To test this, I found it easiest to temporarily move the call to
key_state_export_keying_material outside the if statement, and use a
script that runs after connection setup (e.g. --ipchange) that prints
the environment. E.g.
#!/bin/sh
env | sort
This should show the same value for the exported_keying_material env
variable for both mbed TLS and OpenSSL builds. Of course you can also
use the code as-is, and write a plugin to verify the same thing.
Signed-off-by: Steffan Karger <steffan@karger.me> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20191110231018.30621-1-steffan@karger.me>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19111.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Wed, 8 Jan 2020 11:52:24 +0000 (12:52 +0100)]
wintun: stop sending TAP-Windows6 ioctls to NDIS device
Wintun doesn't have its own I/O device. Rather, it taps on existing
Windows-provided NDIS device. Sending TAP-Windows6 IOCTL requests to it
is risky, as TAP-Windows6 is using one of the well-known device types
(FILE_DEVICE_UNKNOWN) with function IDs as 1, 2, 3 etc. raising a chance
of collision as NDIS might react to one of these IOCTLs.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200108115224.38-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19309.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Fri, 20 Dec 2019 19:38:05 +0000 (20:38 +0100)]
wintun: register ring buffers when iterating adapters
Wintun adapters may be considered available if ring buffer registration
succeeded. Therefore, we must attempt to register ring buffers when
iterating adapters and continue on failure.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20191220193805.34-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19288.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Fri, 20 Dec 2019 16:11:13 +0000 (17:11 +0100)]
tun.c: make wintun_register_ring_buffer() non-fatal on failures
Wintun allows multiple handles to be opened on it's NDIS device pipe.
Just by succeeding to open the pipe does not warrant the adapter is
unused.
When iterating for available Wintun adapter, we will need to try
registering ring buffers with each one to actually determine which one
is used and which one is not.
Therefore, a failure to register ring buffers should be detectable, but
not M_FATAL.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20191220161117.1434-3-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19283.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Simon Rozman [Fri, 20 Dec 2019 16:11:11 +0000 (17:11 +0100)]
tun.c: make Windows device lookup functions more general
Since the introduction of Wintun, not all network devices in Windows are
TAP-Windows6. Rather than returning a simple true/false answer, a couple
of functions were reworked to return a corresponding struct tap_reg *
or NULL instead.
As it would make the code `tr = is_tap_win(...)` a bit awkward those
functions (both static) were renamed to better reflect their nature.
Signed-off-by: Simon Rozman <simon@rozman.si> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20191220161117.1434-1-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19280.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Wed, 13 Nov 2019 10:42:16 +0000 (12:42 +0200)]
tun.c: refactor open_tun() implementation
This makes Windows's tun_open() method easier to read
by factoring out blocks of code, which perform certain task,
into separate functions. This also minimizes inflation of
if (!tt->wintun) { }
blocks.
While patch looks big and scary, there are no functional changes
at all, just tossing code around.
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Simon Rozman <simon@rozman.si>
Message-Id: <20191113104216.1545-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19137.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Tue, 17 Dec 2019 12:50:41 +0000 (14:50 +0200)]
wintun: interactive service support
Wintun requires ring buffers registration to be
performed by privileged process. In order to use
openvpn with wintun by non-Administrator, we
need to use interactive service and shared memory
to register buffers.
Openvpn process creates memory mapping object and event
for send and receive ring and passes handles to interactive
service. There handles are duplicated and memory mapped
object is mapped into the address space of service process.
Then address of mapped view and event handle is passed to
wintun kernel driver.
After interactive service preformed registration,
openvpn process maps memory mapped object into
own address space. Thus mapped views in openvpn
and service process represent the same memory region.
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Simon Rozman <simon@rozman.si>
Message-Id: <20191217125041.207-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19244.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Tue, 17 Dec 2019 12:44:10 +0000 (14:44 +0200)]
wintun: ring buffers based I/O
Implemented according to Wintun documentation
and reference client code.
Wintun uses ring buffers to communicate between
kernel driver and user process. Client allocates
send and receive ring buffers, creates events
and passes it to kernel driver under LocalSystem
privileges.
When data is available for read, wintun modifies
"tail" pointer of send ring and signals via event.
User process reads data from "head" to "tail" and
updates "head" pointer.
When user process is ready to write, it writes
to receive ring, updates "tail" pointer and signals
to kernel via event.
In openvpn code we add send ring's event to event loop.
Before performing io wait, we compare "head" and "tail"
pointers of send ring and if they're different, we skip
io wait and perform read.
This also adds ring buffers support to tcp and udp
server code.
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Simon Rozman <simon@rozman.si>
Message-Id: <20191217124410.81-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19243.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Wed, 4 Dec 2019 11:08:36 +0000 (12:08 +0100)]
Add support for OpenSSL TLS 1.3 when using management-external-key
For TLS versions 1.0 to 1.2 and OpenSSL 1.1.0 and requires a PKCS1
padded response for the external key implementation.
As TLS 1.3 mandates RSA-PSS padding support and also requires an
TLS 1.3 implementation to support RSA-PSS for older TLS
version, OpenSSL will query us to sign an already RSA-PSS padded
string.
This patch adds an 'unpadded' and 'pkcs1' parameter to the
management-external-key option to signal that the client is
able to support pkcs1 as well as unpadded signature requests.
Since clients that implement the management-external-key interface
are usually rather tightly integrated solutions (OpenVPN Connect in the
past, OpenVPN for Android), it is reasonable to expect that
upgrading the OpenSSL library can be done together with
management interface changes. Therefore we provide no backwards
compatbility for mangement-interface clients not supporting
OpenSSL 1.1.1. Also doing this would require downgrading TLS
to 1.1.
Using the management api client version instead the parameters to
management-external-key might seem like the more logical way
but since we only know that version very late in connection progress,
it would require extra logic and complexity to deal with this asynchronous
behaviour. Instead just give an error early if OpenSSL 1.1.1 and
management-external-key without nopadding is detected.
The interface is prepared for signalling PCKS1 and RSA-PSS support
instead of signalling unpadded support.
Patch v3: fix overlong lines and few other style patches. Note
two overlong lines concerning mbedtls are not fixed as they
are removed/shortend by the mbed tls patch to avoid conflicts
Patch v4: Setting minimum TLS version proved to be not enough and
instead of implementing a whole compability layer we require
mangement-clients to implement the new feature when they want
to use OpenSSL 1.1.1
Add a padding=ALGORITHM argument to pk-sig to indicate the
algorithm. Drop adding PKCS1 ourselves.
Patch v5: Send the right version of the patch
Patch v6: rebase on master
Patch v7: change style and reword documentation. Make things more
consistent.
Patch v8: fix spellings, grammar.
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20191204110836.6364-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19219.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Fri, 22 Nov 2019 14:33:14 +0000 (15:33 +0100)]
Make tls_version_max return the actual maximum version
Before OpenSSL 1.1.1 there could be no mismatch between
compiled and actual OpenSSL version. With OpenSSL 1.1.1 we need
runtime detection to detect the actual best TLS version supported.
Allowing this runtime detection also allows removing some of the
TLS 1.3/OpenSSL 1.1.1 #ifdefs
Without this patch tls-min-version 1.3 or-highest will actually
downgrade to TLS 1.2 in the "compiled with 1.1.0 and linked against
1.1.1" scenario.
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Selva Nair <selva.nair@gmail.com>
Message-Id: <20191122143315.8564-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19186.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Selva Nair [Tue, 19 Nov 2019 17:03:43 +0000 (12:03 -0500)]
Fix ACL_CHECK_ADD_COMPILE_FLAGS to work with clang
Some compilers (e.g., clang) only issue a warning for
unsupported options unless an additional flag such
as -Werror is used to convert the warning to an error.
The behaviour is unchanged when using gcc as it either
errors or ignores unknown options whether or not -Werror
is present.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1574183023-6136-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19170.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
mbedtls_md_get_size() returns unsigned char, while EVP_MD_size() returns
int. Results coming from both functions are normally in a uint8_t member
of the key_type struct, because it is known that 8bits are enough (also
for EVP_MD_size()).
This unexpected cast can, however, trigger unsolicited warnings.
Make the cast explicit by changing the return value of our crypto API.
Reported-by: Arne Schwabe <arne@rfc2549.org> Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20191110133525.6069-2-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19093.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
auth_token_kt: ensure key_type object is initialized
Fixes the following warning:
auth_token.c: In function 'auth_token_init_secret':
auth_token.c:47: warning: 'kt.cipher_length' is used uninitialized in this
function
auth_token.c:34: note: 'kt.cipher_length' was declared here
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20191110133525.6069-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19092.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
get rid of 'broadcast' argument when configuring the tun device
The broadcast argument is actually useless as every platform will figure
it out and configure it on its own. We even realized that on linux, if
you configure it wrong, nothing wrong will happen.
At this point, let's make the code cleaner and let's get rid of this
useless argument at all.
This patch just removed any occurrence of 'broadcast'.
Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191110124407.8734-1-a@unstable.cc>
URL: https://www.mail-archive.com/search?l=mid&q=20191110124407.8734-1-a@unstable.cc Signed-off-by: Gert Doering <gert@greenie.muc.de>
GCC>=8 supports truncation checking, however the logic is somewhat
fragile when it comes to evaluating strncpy().
In buffer.h we have implemented a wrapper called strncpynt() which
ensures we always do the right hting in the code and reduce the chance
of having bugs.
This said, it seems that the gcc logic is not able to always understand
if we are doing the right thing and throws a false positive.
Toa void the noise, disable truncation checking on Linux by default.
Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191110100323.13206-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19085.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Thu, 7 Nov 2019 17:45:25 +0000 (19:45 +0200)]
wintun: implement opening wintun device
To open wintun device, we cannot use "\\.\Global\Wintun<luid>"
path as before. To get device path which we supply to CreateFile,
we have to use SetupAPI to:
- enumerate network adapters with "wintun" as component id
- for each adapter save its guid
- open device information set
- for each item in set
- open corresponding registry key to get net_cfg_instance_id
- get symbolic link name of device interface by instance id
- path will be symbolic link name of device instance matched with
adapter's guid
See
https://github.com/OpenVPN/openvpn3/blob/master/openvpn/tun/win/tunutil.hpp
and
https://github.com/WireGuard/wireguard-go/blob/master/tun/wintun/wintun_win
dows.go for
implementation examples.
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Simon Rozman <simon@rozman.si>
Message-Id: <1573148729-27339-4-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19029.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
VLAN: implement support for forwarding only pre-tagged VLAN packets
By building on top of the VLAN basic support, allow the user to configure
the server in VLAN_TAGGED-only mode. This way, only packets that reach
the TAP interface with an 802.1Q header are considered for forwarding -
untagged packets are all dropped.
A VLAN-tagged packet is then treated like any other packet by the
OpenVPN routing engine, with the exception of being allowed to reach
only clients configured with the same VID.
The logic applies to all server-to-client and client-to-client traffic.
Signed-off-by: Fabian Knittel <fabian.knittel@lettink.de> Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191009143422.9419-7-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18918.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
is_ipv_X: add support for parsing IP header inside a 802.1q frame
Extend is_ipv_X() routine by properly parsing 802.1q frame rather than
dropping them.
This change is required in order to allow OpenVPN to accept VLAN tagged
frames, which otherwise would be dropped when trying to access the inner
IP header.
While at it, slightly fix the function style.
Signed-off-by: Fabian Knittel <fabian.knittel@lettink.de> Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191009143422.9419-6-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18916.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
maddr: export VLAN ID from client context to maddr object
When receiving a packet from a client, the associated maddr needs to
carry also the VID associated with that client. This way the VID can be
appended to the packet later, if needed.
This patch adds support for exporting the VID from the client context to
the related per-packet maddr object.
Signed-off-by: Fabian Knittel <fabian.knittel@lettink.de> Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191009143422.9419-4-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18917.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
This patch introduces basic support for VLAN tagging on the server side.
The introduced functionality consists in allowing the user to assign
a VID to the server TAP device and a VID to each client port.
Client specific VID are assigned by means of files in CCD (like for
other client specific settings).
Once VIDs have been assigned, everything works as before, except that
communications are allowed only between hosts having the same VID.
With this patch all broadcast and client-to-client traffic is yet
separated by VLAN: only client-to-server unicasts are affected.
Signed-off-by: Fabian Knittel <fabian.knittel@lettink.de> Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20191009143422.9419-3-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18924.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering [Sun, 20 Oct 2019 15:00:39 +0000 (17:00 +0200)]
Force combinationation of --socks-proxy and --proto UDP to use IPv4.
Our current socks.c code does not handle IPv6 + UDP mode (socket
negotiated with server is IPv4-only, addresses passed in the
packets are IPv4-only). If this combination is specified, print
an explanatory message and force IPv4-only.
While at it, extend socks.c code to print address+port of auxiliary
UDP connection to SOCKS server (helps debugging).
Trac: #1221
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191020150039.21516-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18952.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering [Wed, 9 Oct 2019 12:00:43 +0000 (14:00 +0200)]
OpenSolaris/OpenIllumos: use /bin/bash if available for test scripts.
t_client.sh relies on "echo -e" and "echo -n" to produce nicely
looking output, which fails on Solaris /bin/sh - force SHELL=/bin/bash
on recent-enough Solaris variants that have it.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20191009120043.22692-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18914.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering [Wed, 9 Oct 2019 09:52:00 +0000 (11:52 +0200)]
Fix IPv6 routes on tap interfaces on OpenSolaris/OpenIndiana
The "route add" code always used "metric 0" on OpenSolaris, because
(on tun interfaces) it was required to make the route work on
"non-ethernet" interfaces (connected, no NDP).
This breaks routes via tap interfaces on recent Solaris versions
(tested on OpenIndiana 2019) - there, routes only work if metric
is != 0 (or just not set). Otherwise it tries to map the gateway
address to a local address and fails.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191009095200.9337-2-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18906.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering [Wed, 9 Oct 2019 09:51:59 +0000 (11:51 +0200)]
repair tap mode on OpenSolaris/OpenIndiana
commit 611fcbc48 joined the two distinct calls for "add ipv6 address
to tap interface" and "set MTU" for Solaris - but due to peculiarities
on how this platform handles IPv6 addresses ("ifconfig addif" creates
a new "tap0:1" subinterface with the new address - which does not have
a distinct MTU) this does not work.
un-join calls again.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191009095200.9337-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18905.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Tue, 17 Sep 2019 12:33:21 +0000 (14:33 +0200)]
Implement unit tests for auth-gen-token
The unit test is breaking the 80 char limit in some places
but the remaining lines it breaks the limit I feel
forcing the 80 char limit will impair readibility
Patch V2: adapt unit tests to other V2 patches
Patch V4: Resolve rebase conflicts
Patch V5: Add \ lost in rebase that broke compilation
Patch V7: Fix unit test failure, try to stay below 80 Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20190917123321.15993-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18821.html
David Sommerseth [Fri, 27 Sep 2019 22:45:35 +0000 (00:45 +0200)]
auth-token: Fix compiler complaints with --disable-management
When building with --disable-management, the compiler complains with
implicit declaration of function ‘ssl_clean_auth_token’. This is due to
the ssl_clean_auth_token() function being declared inside an #ifdef
ENABLE_MANAGEMENT fence where it should not be.
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190927224536.27480-3-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18873.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
David Sommerseth [Fri, 27 Sep 2019 22:45:34 +0000 (00:45 +0200)]
auth-token: Fix building with --disable-server
The final patches of the auth-token hmac support patches had a typo in
the P2MP_SERVER fencing breaking --disable-server builds. It used #if
instead of #ifdef.
While at it, also fix another missing P2MP_SERVER fencing causing the
compiler to complain about an unused variable in push.c
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190927224536.27480-2-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18875.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Tue, 17 Sep 2019 12:11:15 +0000 (14:11 +0200)]
Sent indication that a session is expired to clients
This allows OpenVPN 3 core to fall back to the original authentication
method.
This commit changes man_def_auth_set_client_reason to
auth_set_client_reason since it now used in more contexts.
Also remove a FIXME about client_reason not being freed, as it is freed
in tls_multi_free with auth_set_client_reason(multi, NULL);
Patch V4: Rebase on master
Patch V7: Rebase on master Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20190917121115.13966-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18820.html
Arne Schwabe [Tue, 17 Sep 2019 12:10:39 +0000 (14:10 +0200)]
Implement a permanent session id in auth-token
This allows an external authentication method
(e.g. management interface) to track the connection and distinguish a
reconnection from multiple connections.
Addtionally this now also checks to workaround a problem with
OpenVPN 3 core that sometimes uses a username hint from the config
instead of using an empty username if the token would be valid
with an empty username. Accepting such token can be only done
explicitly when the external-auth keyword to auth-gen-token is present.
Patch V2: Add Empty variants to work around behaviour in openvpn 3
Patch V3: document the behaviour of external-auth better in the man page,
rename 'auth' parameter to 'external-auth'
Patch V4: Rebase on current master
Patch V6: Fix tls_lock_username rejecting clients with empty username
when explicitly accepting them with external-auth
Patch V7: Fix compiling with disable-server
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20190917121039.13791-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18819.html
Arne Schwabe [Tue, 17 Sep 2019 12:10:04 +0000 (14:10 +0200)]
Rewrite auth-token-gen to be based on HMAC based tokens
The previous auth-token implementation had a serious problem, especially
when paired with an unpatched OpenVPN client that keeps trying the
auth-token (commit e61b401a).
The auth-token-gen implementation forgot the auth-token on reconnect, this
lead to reconnect with auth-token never working.
This new implementation implements the auth-token in a stateles variant. By
using HMAC to sign the auth-token the server can verify if a token has been
authenticated and by checking the embedded timestamp in the token it can
also verify that the auth-token is still valid.
Using the new config directive auth-gen-token-secret instead of
extending auth-gen-token (--auth-gen-token [lifetime] [secret-key]) was
chosen to allow inlining the secret key.
Patch V2: cleaned up code, use refactored read_pem_key_file function
Patch V3: clarify some design decision in the commit message
Patch V4: Use ephermal_generate_key
Patch V5: Use C99 PRIu64 instead of %lld int printf like statement,
fix strict aliasing
Patch V6: Rebase on master
Patch V7: fix compiling with --disable-server
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20190917121004.13685-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18818.html