Conflicts:
acinclude.m4
config-win32.h
configure.ac
misc.c
thread.c
thread.h
- These conflicts was mainly due to feat_misc getting old
and mostly caused by the pthread clean-up patches in
feat_misc
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
These code paths was practically not needed with no locking mechanisms
enabled and was just bloating the source code.
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: James Yonan <james@openvpn.net>
Problem: using --ping and --inactive together partially defeats the
point of using --inactive as periodic ping packets are counted as
activity. Here is the original discussion:
http://article.gmane.org/gmane.network.openvpn.devel/3676
It turns out that "activity" is detected and recorded in two places
in the code, both in forward.c: in process_outgoing_tun() for received
packets, after they've been decrypted and sent to the TUN device; and
in process_outgoing_link(), after they've been encrypted and written
to the network socket.
In the first case we can be sure that packets that get so far are
really due to user activity, whereas in the second case there can be
non-user packets (like OpenVPN's internal ping packets, and TLS control
packets), and those should not be counted as activity as they are not
coming from the user.
So a need arises to detect those control packets and not count them as
activity for the purposes of --inactive. Unfortunately, at that stage
packets are already compressed and encrypted, so it's not possible to
look into them to see what they are. However, there seems to be a
convention in the code that packets whose buffer length in the context_2
structure is 0 should be ignored for certain purposes. TLS control
packets follow that convention already, so this patch makes a small
change in the code that generates the ping packets to set their buffer
length to 0 as well.
Finally, the call to register_activity() in process_outgoing_link() is
made conditional to the buffer length being > 0.
According to my tests, now --inactive behaves correctly according to
the configured parameters (time or time+bytes) even when --ping is
being used.
forward.c:
Call register_activity() in process_outgoing_link() only if the
packet is not a ping or TLS control packet.
openvpn.8:
Updated the description of --inactive to describe the new semantics.
ping.c:
Set c->c2.buf.len = 0 after the ping packet has been generated and
encrypted.
Test routine is described here:
<https://community.openvpn.net/openvpn/wiki/PingInactivePatch?version=6>
Signed-off-by: Davide Brini <dave_br@gmx.com>
Acked-by: David Sommerseth <dazo@users.sourceforge.net>
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
With --verb 5, openvpn logs a single letter (rwRW) for each package
received or sent. I recently ran into a problem with the tun device on
Linux where the read from that device returned 0. Unfortunately this was
also logged as "r", which made me assume that openvpn had received
something, while it actually hadn't.
(See https://dev.openwrt.org/ticket/6650 for the bug that made me find out
about this problem with openvpn.)
I'm attaching a patch which prevents openvpn from logging "r" or "R" when
it didn't actually read anything. This is against openvpn 2.1-rc20, but
probably still applies to the most recent version.
This patch was received anonymously via the sf.net bug tracker:
<http://sourceforge.net/tracker/?func=detail&atid=454719&aid=2951003&group_id=48978>
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
easier for OpenVPN client UIs to start a pre-existing client config file with
proxy options, or to adaptively fall back to a proxy connection if a direct
connection fails.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@5652 e7ae566f-a301-0410-adde-c780ea21d3b5
With --verb 5, openvpn logs a single letter (rwRW) for each package
received or sent. I recently ran into a problem with the tun device on
Linux where the read from that device returned 0. Unfortunately this was
also logged as "r", which made me assume that openvpn had received
something, while it actually hadn't.
(See https://dev.openwrt.org/ticket/6650 for the bug that made me find out
about this problem with openvpn.)
I'm attaching a patch which prevents openvpn from logging "r" or "R" when
it didn't actually read anything. This is against openvpn 2.1-rc20, but
probably still applies to the most recent version.
This patch was received anonymously via the sf.net bug tracker:
<http://sourceforge.net/tracker/?func=detail&atid=454719&aid=2951003&group_id=48978>
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
or "dhcp-renew" options were combined with "route-gateway dhcp".
The problem is that the IP Helper functions for DHCP release and
renew are blocking, and so calling them from a single-threaded
client stops tunnel traffic forwarding, and hence breaks
"route-gateway dhcp" which requires an active tunnel. The fix is
to call the IP Helper functions for DHCP release and renew from
another process.
Version 2.1_rc21b.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@5164 e7ae566f-a301-0410-adde-c780ea21d3b5
now send a RESTART message to client.
This feature is intended to make UDP clients respond the same as TCP
clients in the case where the server issues a RESTART message in
order to force the client to reconnect and pull a new options/route
list.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@5021 e7ae566f-a301-0410-adde-c780ea21d3b5
after connection initiation rather than 0 seconds after.
Successive PUSH_REQUEST messages after the first will continue to be
sent at 5 second intervals until a response is received. This tends
to speed up the client connection sequence by 4 seconds because the
first PUSH_REQUEST message is usually sent too soon and is dropped,
causing a wait of 5 seconds until the next PUSH_REQUEST message is
sent.
Version 2.1_rc19d
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@4965 e7ae566f-a301-0410-adde-c780ea21d3b5
domain socket, for example:
management /tmp/openvpn unix
Also added management-client-user and management-client-group
directives to control which processes are allowed to connect
to the socket.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@3396 e7ae566f-a301-0410-adde-c780ea21d3b5
DHCP proxy mode: Configure server mode for ethernet
bridging using a DHCP-proxy, where clients talk to the
OpenVPN server-side DHCP server to receive their IP address
allocation and DNS server addresses.
Added "--route-gateway dhcp", to enable the extraction
of the gateway address from a DHCP negotiation with the
OpenVPN server-side LAN.
Modified client.conf and server.conf to reflect new option
modes.
Incremented version to 2.1_rc9a.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@3164 e7ae566f-a301-0410-adde-c780ea21d3b5
Added client authentication and packet filtering capability
to management interface.
Extended packet filtering capability to work on both --dev tun
and --dev tap tunnels.
Updated valgrind-suppress file.
Made "Linux ip addr del failed" error nonfatal.
Amplified --client-cert-not-required warning.
Added #pragma pack to proto.h.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@2991 e7ae566f-a301-0410-adde-c780ea21d3b5
Support asynchronous authentication by plugins by allowing
OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY to return
OPENVPN_PLUGIN_FUNC_DEFERRED. See comments in
openvpn-plugin.h for documentation. Enabled by ENABLE_DEF_AUTH.
Added a simple packet filter functionality that can be driven by
a plugin. See comments in openvpn-plugin.h for documentation.
Enabled by ENABLE_PF.
See openvpn/plugin/defer/simple.c for examples of ENABLE_DEF_AUTH
and ENABLE_PF.
"TLS Error: local/remote TLS keys are out of sync" is no longer a
fatal error for TCP-based sessions, since the error can arise
normally in the course of deferred authentication. In a related
change, allow packet-id sequence to begin at some number n > 0 for
TCP sessions, rather than strictly requiring sequence to begin
at 1.
Added a test to configure.ac for LoadLibrary function on Windows.
Modified "make dist" function to include all files from
install-win32 so that ./domake-win can be run from a
tarball-expanded directory.
setenv and setenv-safe directives may now omit a value argument
which defaults to "".
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@2978 e7ae566f-a301-0410-adde-c780ea21d3b5
* Added code to make sure that the local PATH environmental
variable points to the Windows system32 directory.
* Added new --ip-win32 adaptive mode which tries 'dynamic'
and then fails over to 'netsh' if the DHCP negotiation fails.
* Made --ip-win32 adaptive the default.
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@739 e7ae566f-a301-0410-adde-c780ea21d3b5
