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>
Using AsioWork directly inside a ResolveThread resulted in the
impossibility of the core to kill it, thus re-creating the original
problem of requiring the core thread to wait for the resolve to be
finished.
The original "i/o queue can be empty problem" appears only in case we
are performing a pre-resolve operation, because this is when there is
nothing else scheduled for the i/o reactor. Resolution operation within
tcp/udp/http clients do not really have this problem because they happen
in an already active context.
For this reason AsioWork can be moved out of the resolve thread and can
be used only during pre-resolve.
At the same time we want to retain control of the AsioWork object
because we HAVE TO kill it when the core is trying to stop. This
operation will ensure that the i/o reactor can be immediately
terminated.
For this reason, we move the AsioWork object into in the AsyncResolvable
class that is always reachable and allows the core to kill the Asiowork
object when needed (this was impossible when AsioWork was part of
ResolveThread).
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
On Android local networks need to be excluded from the default (or any
other route) route if they should bypass the VPN. This adds a callback
to specifically bypass the local LAN networks.
The old route emulation would immediately stop if the 0.0.0.0/0 was
in the routes to install.
Replace the old approach by first calculation a fine grained enough
set of routes and then only install those routes from this set that
should go via the VPN.
The core might be asked to solve several hostnames and for this reason
it is racy to use one AsioWork object to coordinate them all.
The reason why it is racy is that a thread may likely be unsetting the
AsioWork object while we still have another ongoing resolution. This
will lead to the original problem of "the i/o queue is empty, core can
exit now".
To fix this, create a standalone ResolveThread class that is
instantiated once per resolve operation and that contains its private
AsioWork object.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
The commit 8b22a7b2 had two mistakes:
Accidentally moving the #endif to the wrong line during reformat.
Forgetting to include mbedtls/version.h so the version check was always
false.
When ASIO performs an async DNS resolution, it relies on the
getaddrinfo() syscall in order to obtain a result.
This syscall is non-interruptible by design, which means that, in case
of sudden stop command received by the user, the core will not be able
to terminate all its threads until the getaddrinfo() has returned
(either by timeout or with a result).
If the the external core user is synchronously waiting for it to
terminate (i.e. like a UI), this behaviour will lead to the entire
client hanging.
To avoid this issue, this commit converts each asynchronous DNS
resolution to a synchrnous one performed in a detached thread.
This way, if the core wants to stop, it can do so without waiting for
the DNS thread to join. Otherwise, this change should not lead to any
functional difference.
Signed-off-by: Yuriy Barnovych <yuriy@openvpn.net>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
When receiving packed from tun which size exceeds
mssfix value minus encap overhead, send ICMP
"destination unreachable" / "fragmentation needed"
(for IPv4) or "packet too big" (for IPv6) response.
This is required for non-TCP based protocols, since
for TCP we alter MSS in SYN segments.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Enable remote_bypass and pass full remote list to the macOS client,
so that it can connect to the next remote in case of reconnection.
Without remote_bypass enabled, the client will not be able to reach any
other server, when all the traffic is going through the VPN.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Enable remote_bypass and pass full remote list to the Windows client,
so that it can connect to the next remote in case of reconnection.
Without remote_bypass enabled, the client will not be able to reach any
other server, when all the traffic is going through the VPN.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Adds mssfix support including optional
transport overhead. Some code has been ported
from openvpn2.
mssfix sets MSS option in TCP SYN to
a calculated value which guarantees that
size of UDP/TCP packet (which may or may not
include headers, see below) encapsulating
TCP segments won't exceed mssfix value.
If mssfix is used with optional "mtu" parameter,
then IP and UDP/TCP headers are also taken into account.
It is set in config like this:
mssfix 1300 mtu
Signed-off-by: Lev Stipakov <lev@openvpn.net>
