There are two ways how Linux tun can be manipulated -
by using iproute2 or netlink. Both implementations have
defined identical Setup class implementation.
This commit factors out Setup class from tun implementations
and templatizes it, which removes need in duplicated code.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
When porting this patch I accidentally got the conflict backwards and
the resulting patch is nonsense. I am not sure how this managed to
survive a full Jenkins run.
The asio upgrade of 0.1.13 brought us over the limit of 65k
entitities in a single compilation unit. /bigobj allows more
methods
The ovpn3-core.vcxproj already uses this flag
commit e9c0bd00be
Author: Arne Schwabe <arne@openvpn.net>
Date: Tue Oct 23 13:47:07 2018 +0200
Remove unused private field
crypto_init_ is not used at all and since it is a private field it is
safe to remove.
We also revert the following commit which is redundant once the above
commit is reverted.
commit d87f5bbc04
Author: Antonio Quartulli <antonio@openvpn.net>
Date: Thu Nov 15 21:03:46 2018 +1000
OpenSSL: init library
From the manpage:
"SSL_library_init() must be called before any other action takes place."
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Signed-off-by: James Yonan <james@openvpn.net>
ASIO's code for returning error messages doesn't play well with
non-ASCII chars. This quick fix makes ASIO use English.
A proper fix, which is more invasive (use FormatMessageW and
WideCharToMultiByte with UTF-8) will be provided separately.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Without this fix, some gcc compilers will issue the warning below when
building the reference client:
../../openvpn/common/base64.hpp: In constructor
‘openvpn::Base64::UCharWrap::UCharWrap(unsigned char*, size_t)’:
../../openvpn/common/base64.hpp:77:9: warning:
‘openvpn::Base64::UCharWrap::size’ will be initialized after [-Wreorder]
size_t size;
^
../../openvpn/common/base64.hpp:76:17: warning: ‘unsigned char*
openvpn::Base64::UCharWrap::data’ [-Wreorder]
unsigned char *data;
^
../../openvpn/common/base64.hpp:63:2: warning: when initialized here
[-Wreorder]
UCharWrap(unsigned char *data, size_t size):
^
This patch fixes this issue as well as removing a redundant public
declaration and fixing some whitespace issues.
Signed-off-by: David Sommerseth <davids@openvpn.net>
Since the Core Library doesn't really handle TAP mode, reject
configuration profiles expecting TAP mode as soon as possible.
Signed-off-by: David Sommerseth <davids@openvpn.net>
The TunWin::ClientConfig::layer_2_supported() returns true, while the
rest of the Core library does not handle TAP mode/OSI Layer 2 packets at
all. This causes a challenge on Windows as it needs to have TAP support
on the virtual network device side - the tap-windows6 driver is TAP
only. So this method must return true. Currently OpenVPN just emulates
TAP mode by encapuslating TUN packets into somewhat proper Ethernet
frames.
Signed-off-by: David Sommerseth <davids@openvpn.net>
In TLS 1.3 the RSA-PSS padding is required in addition to the
traditional PKCS1 padding used in TLS 1.2 and below. Add an
argument to the external sign function to signal what padding
is required. As quirkyness OpenSSL calls out requesting a NONE
padding instead of RSA-PASS.
We might need to move from RSA_method to EVP_PKEY_method in the
future.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
In OpenSSL 1.1 most types are opaque types that cannot directly accessed
or initialised. Accordingly change ctx to a pointer.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The OpenSSL manpage also points to use a function like (SSL_get_ex_data).
And we already use this functionality for storing and getting the SSL
class instance.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The OpenSSL 1.1 check is a bit stricter than our own custom check but
OpenVPN 2.x uses the same (stricter) check.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The old logic was not matching and was also dubious (probably due the
confusion of OpenSSL TLS1_method meaning TLS 1.0 only)
Signed-off-by: Arne Schwabe <arne@openvpn.net>
We modified the TLS method in OpenSSL. As accessing struct members is
no longer possible and OpenSSL does provide not access functions for
internal members, this hack cannot be supported anymore.
Clarify the comment of ssl_pending why it is needed
Signed-off-by: Arne Schwabe <arne@openvpn.net>
This code surrunding the new allocation expects to have new return
nullptr in case it fails. By default however new throws an expection.
Use std::nothrow to make new behave as the code expects.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
NodeJS C++ environment defines ssize_t and causes
core build to fail because of type redefinition.
To fix, surround core's definition with same #ifdef guards
used in Node.JS.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
The new thread we create to perform the async DNS resolution must be
fully detachable. This is a strong requirement, because its parent (the
AsyncResolvable class) and the core itself may disappear by the time the
DNS resolution thread is ready to post the callback.
This situation can easily happen when the DNS resolution is hanging on a
non-working network, while the user has already terminated the core by
explicitly clicking 'disconnect' on the the UI.
Fix this issue by creating a ResolveThread class which can receive
a 'detach' signal from the parent when the latter is about to disappear.
The ResolveThread will then be able to understand that it was left alone
and will not post any callback.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
* schwabe/UCONNECT-1186-fix-custom-memcpy:
Replace custom memcpy implementation
Workaround for compiler bug in memneq
[UCONNECT-1027] use one AsioWork object for the whole pre-resolve opertation
Revert "[UCONNECT-1027] remotelist: create standalone object for resolve thread"
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The custom memcpy implementation is not faster than the
standard memcpy in my tests (standard one is assembler optimised on
almost all platforms).
Also the custom memcpy version crashes with a segfault on a current
Android clang/arm32 compiler. I suspect this due to the fact that it
ignores memory alignment.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
