Re: [Openvpn-devel] [PATCH 11/14] Remove P2MP mode and check for gettimeofday
Am 01.04.21 um 15:13 schrieb Arne Schwabe: > Using OpenVPN without P2MP support (pull, TLS) is unrealistic and > building a binary without it is not something we realistically want > to support anyway. > } > +/* Check if we have forbidding options in the current mode */ > +if (dco_enabled( >context.options) Ignore this patch for now. Rebasing worked without conflicts but somehow still pull dco bits into it (rebase is sometimes magic ) Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Move is_proto function to the socket.h header
Acked-by: Gert Doering Moved and compacted somewhat, but "the same functions". Having a "proto_is_dgram()" sounds a bit silly since we're not doing "openvpn over IPX" or anything other dgram based, but who knows... maybe we'll grow IPX/SPX support and "proto_is_stream()" one day... :-) Client-side tested on Linux and FreeBSD, just to be sure. Your patch has been applied to the master branch. commit 72e1ecb5b5d282c591cc32bbd378efbebfb03918 Author: Arne Schwabe Date: Thu Apr 1 15:13:32 2021 +0200 Move is_proto function to the socket.h header Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-10-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21950.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Remove unused variable pass_config_info
Acked-by: Gert Doering "git grep" confirms. Your patch has been applied to the master branch. commit 9eb285f42f73bcfb270adbae527947951615df7d Author: Arne Schwabe Date: Thu Apr 1 15:13:28 2021 +0200 Remove unused variable pass_config_info Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-6-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21948.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Remove unused function tls_test_auth_deferred_interval
Acked-by: Gert Doering "git grep" confirms Your patch has been applied to the master branch. commit c0b36e9f29c9849892909a7e377e13db6aa59f95 Author: Arne Schwabe Date: Thu Apr 1 15:13:31 2021 +0200 Remove unused function tls_test_auth_deferred_interval Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-9-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21949.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Remove unused field txqueuelen from struct tuntap
Acked-by: Gert Doering As far as I can see, only Linux uses txqueuelen at all, and that one still compiles with this patch applied. Out it goes! Your patch has been applied to the master branch. commit 3667df1d668420374d91607685b67a0efbcee328 Author: Arne Schwabe Date: Thu Apr 1 15:13:30 2021 +0200 Remove unused field txqueuelen from struct tuntap Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-8-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21947.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Remove pointless tun_adjust_frame_parameters function
Acked-by: Gert Doering .. indeed! Your patch has been applied to the master branch. commit 14061e3e06075065fba1939d3716fbd09f9adf70 Author: Arne Schwabe Date: Thu Apr 1 15:13:29 2021 +0200 Remove pointless tun_adjust_frame_parameters function Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-7-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21957.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Remove code for aligning non-swapped compression
Acked-by: Gert Doering I was a bit worried about this breaking existing setups, and then Arne remarked that "this is dead code anyway" - it is only compiled if built with --disable-lz4, which we do for testing on some buildbots, but not for production builds. So, ripping out dead code is not going to break anything. Still, lightly client side tested on Linux. With compression :) Your patch has been applied to the master branch. commit 137eb6705e57d3324fe45367419413e34a424976 Author: Arne Schwabe Date: Thu Apr 1 15:13:24 2021 +0200 Remove code for aligning non-swapped compression Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-2-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21946.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Rename tunnel_server_udp_single_threaded to tunnel_server_udp
Acked-by: Gert Doering "Because it makes sense". There's no threads here, and with DCO and all the asyncness, there might never be... so, admit that fact :-) Lightly client-side tested on linux. Your patch has been applied to the master branch. commit bdc11ae462d61f0cdee5f539c7f028f58513a914 Author: Arne Schwabe Date: Thu Apr 1 15:13:26 2021 +0200 Rename tunnel_server_udp_single_threaded to tunnel_server_udp Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-4-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21955.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Remove superflous ifdefs around enum like defines
Acked-by: Gert Doering Totally untested, but stared-at-code for a bit. (This will increase binary for "no management" by some 10-20 bytes, but makes the code easier to understand by not getting distracted by #ifdefs all over the place). Your patch has been applied to the master branch. commit 213fd3ee49e670124d911634c2f52061a82357af Author: Arne Schwabe Date: Thu Apr 1 15:13:25 2021 +0200 Remove superflous ifdefs around enum like defines Signed-off-by: Arne Schwabe Acked-by: Gert Doering Message-Id: <20210401131337.3684-3-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21958.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 04/14] Add documentation on EVENT_READ/EVENT_WRITE constants
Signed-off-by: Arne Schwabe --- src/openvpn/forward.c | 3 ++- src/openvpn/openvpn.h | 12 +++- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c index 6f7a50048..98caf6651 100644 --- a/src/openvpn/forward.c +++ b/src/openvpn/forward.c @@ -1880,7 +1880,8 @@ io_wait_dowork(struct context *c, const unsigned int flags) unsigned int tuntap = 0; struct event_set_return esr[4]; -/* These shifts all depend on EVENT_READ and EVENT_WRITE */ +/* These shifts all depend on EVENT_READ (=1) and EVENT_WRITE (=2) */ +/* and are added to the shift. */ static int socket_shift = 0; /* depends on SOCKET_READ and SOCKET_WRITE */ static int tun_shift = 2; /* depends on TUN_READ and TUN_WRITE */ static int err_shift = 4; /* depends on ES_ERROR */ diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h index 0ddaeb730..322ab3ee1 100644 --- a/src/openvpn/openvpn.h +++ b/src/openvpn/openvpn.h @@ -245,7 +245,17 @@ struct context_2 int event_set_max; bool event_set_owned; -/* event flags returned by io_wait */ +/* event flags returned by io_wait, + * All these event are their respective shift as defined in io_wait_dowork + * adding a shift of 0 for the READ event and 1 for the write event. + * + * E.g. management_shift = 6; + * MANAGMENT_READ = (1<<(6+0)), + * MANAGEMNET_WRITE = (1<<(6+1)) + * + * Some shifts (error, file_close) are using read/write for diferent + * signals. + */ #define SOCKET_READ (1<<0) #define SOCKET_WRITE (1<<1) #define TUN_READ (1<<2) -- 2.30.1 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 12/14] Extract multi_assign_peer_id into its own function
This makes multi_get_create_instance_udp a bit shorter and better
structured and also prepares this method to be called from the
mutlti TCP context with DCO which will also need to assign unique peer
ids to instances.
Signed-off-by: Arne Schwabe
---
src/openvpn/mudp.c | 20 +---
src/openvpn/multi.c | 21 +
src/openvpn/multi.h | 10 ++
3 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/src/openvpn/mudp.c b/src/openvpn/mudp.c
index 90e32a8ec..9225d42de 100644
--- a/src/openvpn/mudp.c
+++ b/src/openvpn/mudp.c
@@ -103,27 +103,9 @@ multi_get_create_instance_udp(struct multi_context *m,
bool *floated)
mi = multi_create_instance(m, );
if (mi)
{
-int i;
-
hash_add_fast(hash, bucket, >real, hv, mi);
mi->did_real_hash = true;
-
-/* max_clients must be less then max peer-id value */
-ASSERT(m->max_clients < MAX_PEER_ID);
-
-for (i = 0; i < m->max_clients; ++i)
-{
-if (!m->instances[i])
-{
-mi->context.c2.tls_multi->peer_id = i;
-m->instances[i] = mi;
-break;
-}
-}
-
-/* should not really end up here, since
multi_create_instance returns null
- * if amount of clients exceeds max_clients */
-ASSERT(i < m->max_clients);
+multi_assign_peer_id(m, mi);
}
}
else
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 071bd5b61..d4c5304cb 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -4016,6 +4016,27 @@ init_management_callback_multi(struct multi_context *m)
#endif /* ifdef ENABLE_MANAGEMENT */
}
+void multi_assign_peer_id(struct multi_context *m, struct multi_instance *mi)
+{
+/* max_clients must be less then max peer-id value */
+ASSERT(m->max_clients < MAX_PEER_ID);
+
+for (int i = 0; i < m->max_clients; ++i)
+{
+if (!m->instances[i])
+{
+mi->context.c2.tls_multi->peer_id = i;
+m->instances[i] = mi;
+break;
+}
+}
+
+/* should not really end up here, since multi_create_instance returns null
+ * if amount of clients exceeds max_clients */
+ASSERT(mi->context.c2.tls_multi->peer_id < m->max_clients);
+}
+
+
/*
* Top level event loop.
*/
diff --git a/src/openvpn/multi.h b/src/openvpn/multi.h
index b7078b711..9d771f537 100644
--- a/src/openvpn/multi.h
+++ b/src/openvpn/multi.h
@@ -676,5 +676,15 @@ multi_set_pending(struct multi_context *m, struct
multi_instance *mi)
{
m->pending = mi;
}
+/**
+ * Assigns a peer-id to a a client and adds the instance to the
+ * the instances array of the \c multi_context structure.
+ *
+ * @param m- The single \c multi_context structure.
+ * @param mi - The \c multi_instance of the VPN tunnel to be
+ * postprocessed.
+ */
+void multi_assign_peer_id(struct multi_context *m, struct multi_instance *mi);
+
#endif /* MULTI_H */
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 02/14] Remove superflous ifdefs around enum like defines
The variables are not used without the configured options but the
ifdef around them does not help readibility either.
Signed-off-by: Arne Schwabe
---
src/openvpn/mtcp.c| 5 -
src/openvpn/mudp.c| 2 --
src/openvpn/openvpn.h | 4
3 files changed, 11 deletions(-)
diff --git a/src/openvpn/mtcp.c b/src/openvpn/mtcp.c
index 22c824aaa..7d2a69b99 100644
--- a/src/openvpn/mtcp.c
+++ b/src/openvpn/mtcp.c
@@ -59,13 +59,8 @@
#define MTCP_SOCKET ((void *)1)
#define MTCP_TUN ((void *)2)
#define MTCP_SIG ((void *)3) /* Only on Windows */
-#ifdef ENABLE_MANAGEMENT
#define MTCP_MANAGEMENT ((void *)4)
-#endif
-
-#ifdef ENABLE_ASYNC_PUSH
#define MTCP_FILE_CLOSE_WRITE ((void *)5)
-#endif
#define MTCP_N ((void *)16) /* upper bound on MTCP_x */
diff --git a/src/openvpn/mudp.c b/src/openvpn/mudp.c
index e95a7ac81..5af1081fc 100644
--- a/src/openvpn/mudp.c
+++ b/src/openvpn/mudp.c
@@ -195,12 +195,10 @@ multi_process_io_udp(struct multi_context *m)
{
strcat(buf, "TW/");
}
-#ifdef ENABLE_ASYNC_PUSH
else if (status & FILE_CLOSED)
{
strcat(buf, "FC/");
}
-#endif
printf("IO %s\n", buf);
#endif /* ifdef MULTI_DEBUG_EVENT_LOOP */
diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h
index 3cef26381..1063351d3 100644
--- a/src/openvpn/openvpn.h
+++ b/src/openvpn/openvpn.h
@@ -252,13 +252,9 @@ struct context_2
#define TUN_WRITE (1<<3)
#define ES_ERROR (1<<4)
#define ES_TIMEOUT(1<<5)
-#ifdef ENABLE_MANAGEMENT
#define MANAGEMENT_READ (1<<6)
#define MANAGEMENT_WRITE (1<<7)
-#endif
-#ifdef ENABLE_ASYNC_PUSH
#define FILE_CLOSED (1<<8)
-#endif
unsigned int event_set_status;
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 06/14] Remove pointless tun_adjust_frame_parameters function
This functions seem to serve no purpose other than to add confusion.
Signed-off-by: Arne Schwabe
---
src/openvpn/init.c | 2 +-
src/openvpn/tun.h | 10 --
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 1a6015452..f0ae0b7f1 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3101,7 +3101,7 @@ do_init_frame(struct context *c)
*/
if (c->options.ce.tun_mtu_extra_defined)
{
-tun_adjust_frame_parameters(>c2.frame, c->options.ce.tun_mtu_extra);
+frame_add_to_extra_tun(>c2.frame, c->options.ce.tun_mtu_extra);
}
/*
diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h
index 902665cc6..7e8fb7647 100644
--- a/src/openvpn/tun.h
+++ b/src/openvpn/tun.h
@@ -315,16 +315,6 @@ void check_subnet_conflict(const in_addr_t ip,
void warn_on_use_of_common_subnets(openvpn_net_ctx_t *ctx);
-/*
- * Inline functions
- */
-
-static inline void
-tun_adjust_frame_parameters(struct frame *frame, int size)
-{
-frame_add_to_extra_tun(frame, size);
-}
-
/*
* Should ifconfig be called before or after
* tun dev open?
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 13/14] log file descriptor in more socket related error messages
This add the fd to the epoll event error message and the x_check_status
message. This helps debugging when thing go wrong with event handling.
Also add logging when ep_del fails to remove a socket from the structure.
In constract to ep_ctl that has this as a FATAL message (M_ERR), we only
log here since the code has been ignoring the status forever there might
be corner cases where a FATAL message could trigger an unintened regression.
Signed-off-by: Arne Schwabe
---
src/openvpn/error.c | 8
src/openvpn/event.c | 8 ++--
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/openvpn/error.c b/src/openvpn/error.c
index e6f7ff0ff..4eebf41a9 100644
--- a/src/openvpn/error.c
+++ b/src/openvpn/error.c
@@ -690,15 +690,15 @@ x_check_status(int status,
{
if (extended_msg)
{
-msg(x_cs_info_level, "%s %s [%s]: %s (code=%d)", description,
+msg(x_cs_info_level, "%s %s [%s]: %s (fd=%d,code=%d)",
description,
sock ? proto2ascii(sock->info.proto, sock->info.af, true)
: "",
-extended_msg, strerror(my_errno), my_errno);
+extended_msg, strerror(my_errno), my_errno, sock ?
sock->sd : -1);
}
else
{
-msg(x_cs_info_level, "%s %s: %s (code=%d)", description,
+msg(x_cs_info_level, "%s %s: %s (fd=%d,code=%d)", description,
sock ? proto2ascii(sock->info.proto, sock->info.af, true)
: "",
-strerror(my_errno), my_errno);
+strerror(my_errno), my_errno, sock ? sock->sd : -1);
}
if (x_cs_err_delay_ms)
diff --git a/src/openvpn/event.c b/src/openvpn/event.c
index 49dfa861c..14a25155c 100644
--- a/src/openvpn/event.c
+++ b/src/openvpn/event.c
@@ -555,7 +555,10 @@ ep_del(struct event_set *es, event_t event)
ASSERT(!eps->fast);
CLEAR(ev);
-epoll_ctl(eps->epfd, EPOLL_CTL_DEL, event, );
+if (epoll_ctl(eps->epfd, EPOLL_CTL_DEL, event, ) < 0)
+{
+msg(M_WARN|M_ERRNO, "EVENT: epoll_ctl EPOLL_CTL_DEL failed, sd=%d",
(int)event);
+}
}
static void
@@ -844,7 +847,8 @@ po_wait(struct event_set *es, const struct timeval *tv,
struct event_set_return
}
else if (pfdp->revents)
{
-msg(D_EVENT_ERRORS, "Error: poll: unknown revents=0x%04x",
(unsigned int)pfdp->revents);
+msg(D_EVENT_ERRORS, "Error: poll: unknown revents=0x%04x for
fd=%d",
+(unsigned int)pfdp->revents, pfdp->fd);
}
++pfdp;
}
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 14/14] Remove do_init_socket_2 and do_init_socket_1 wrapper function
These two function basically just pass a number of fields of context to
the linit_socket_init1/2 functions. This wrapper add little to no value
in understanding the code, especially since the linit_socket_init1 will
just copy them to yet another structure.
Remove these wrapper functions and pass context directly to the called
function.
Signed-off-by: Arne Schwabe
---
src/openvpn/init.c | 60 +---
src/openvpn/socket.c | 109 +++
src/openvpn/socket.h | 40 ++--
3 files changed, 52 insertions(+), 157 deletions(-)
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 98cc1ebe9..d6dd8675c 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3339,62 +3339,6 @@ do_link_socket_new(struct context *c)
c->c2.link_socket_owned = true;
}
-/*
- * bind the TCP/UDP socket
- */
-static void
-do_init_socket_1(struct context *c, const int mode)
-{
-unsigned int sockflags = c->options.sockflags;
-
-#if PORT_SHARE
-if (c->options.port_share_host && c->options.port_share_port)
-{
-sockflags |= SF_PORT_SHARE;
-}
-#endif
-
-link_socket_init_phase1(c->c2.link_socket,
-c->options.ce.local,
-c->options.ce.local_port,
-c->options.ce.remote,
-c->options.ce.remote_port,
-c->c1.dns_cache,
-c->options.ce.proto,
-c->options.ce.af,
-c->options.ce.bind_ipv6_only,
-mode,
-c->c2.accept_from,
-c->c1.http_proxy,
-c->c1.socks_proxy,
-#ifdef ENABLE_DEBUG
-c->options.gremlin,
-#endif
-c->options.ce.bind_local,
-c->options.ce.remote_float,
->c1.link_socket_addr,
-c->options.ipchange,
-c->plugins,
-c->options.resolve_retry_seconds,
-c->options.ce.mtu_discover_type,
-c->options.rcvbuf,
-c->options.sndbuf,
-c->options.mark,
-c->options.bind_dev,
->c2.server_poll_interval,
-sockflags);
-}
-
-/*
- * finalize the TCP/UDP socket
- */
-static void
-do_init_socket_2(struct context *c)
-{
-link_socket_init_phase2(c->c2.link_socket, >c2.frame,
-c->sig);
-}
-
/*
* Print MTU INFO
*/
@@ -4255,7 +4199,7 @@ init_instance(struct context *c, const struct env_set
*env, const unsigned int f
/* bind the TCP/UDP socket */
if (c->mode == CM_P2P || c->mode == CM_TOP || c->mode == CM_CHILD_TCP)
{
-do_init_socket_1(c, link_socket_mode);
+link_socket_init_phase1(c, link_socket_mode);
}
/* initialize tun/tap device object,
@@ -4299,7 +4243,7 @@ init_instance(struct context *c, const struct env_set
*env, const unsigned int f
/* finalize the TCP/UDP socket */
if (c->mode == CM_P2P || c->mode == CM_TOP || c->mode == CM_CHILD_TCP)
{
-do_init_socket_2(c);
+link_socket_init_phase2(c);
}
/*
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 6fed4b660..6bb107de6 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1876,77 +1876,60 @@ link_socket_new(void)
}
void
-link_socket_init_phase1(struct link_socket *sock,
-const char *local_host,
-const char *local_port,
-const char *remote_host,
-const char *remote_port,
-struct cached_dns_entry *dns_cache,
-int proto,
-sa_family_t af,
-bool bind_ipv6_only,
-int mode,
-const struct link_socket *accept_from,
-struct http_proxy_info *http_proxy,
-struct socks_proxy_info *socks_proxy,
-#ifdef ENABLE_DEBUG
-int gremlin,
-#endif
-bool bind_local,
-bool remote_float,
-struct link_socket_addr *lsa,
-const char *ipchange_command,
-const struct plugin_list *plugins,
-int resolve_retry_seconds,
-int mtu_discover_type,
-int rcvbuf,
-int sndbuf,
-int mark,
-const char *bind_dev,
-struct event_timeout *server_poll_timeout,
-unsigned int sockflags)
[Openvpn-devel] [PATCH 03/14] Rename tunnel_server_udp_single_threaded to tunnel_server_udp
This also eliminates the confusing name and eliminates
tunnel_server_udp as wrapper that only calls
tunnel_server_udp_single_threaded
Signed-off-by: Arne Schwabe
---
doc/doxygen/doc_eventloop.h| 2 +-
doc/doxygen/doc_tunnel_state.h | 2 +-
src/openvpn/mudp.c | 21 ++---
src/openvpn/mudp.h | 7 +++
src/openvpn/openvpn.h | 2 +-
5 files changed, 8 insertions(+), 26 deletions(-)
diff --git a/doc/doxygen/doc_eventloop.h b/doc/doxygen/doc_eventloop.h
index 8bd26355e..e9f7ea6f4 100644
--- a/doc/doxygen/doc_eventloop.h
+++ b/doc/doxygen/doc_eventloop.h
@@ -61,6 +61,6 @@
* event loop function is called to drive the event processing. The
* following implementations are available:
* - Client mode using UDP or TCP: \c tunnel_point_to_point()
- * - Server mode using UDP: \c tunnel_server_udp_single_threaded()
+ * - Server mode using UDP: \c tunnel_server_udp()
* - Server mode using TCP: \c tunnel_server_tcp()
*/
diff --git a/doc/doxygen/doc_tunnel_state.h b/doc/doxygen/doc_tunnel_state.h
index 46e750fda..104df2e91 100644
--- a/doc/doxygen/doc_tunnel_state.h
+++ b/doc/doxygen/doc_tunnel_state.h
@@ -118,7 +118,7 @@
* tunnel_point_to_point() or \c tunnel_server().
*
* In server-mode, \c main() calls the \c tunnel_server() function, which
- * transfers control to \c tunnel_server_udp_single_threaded() or \c
+ * transfers control to \c tunnel_server_udp() or \c
* tunnel_server_tcp() depending on the external transport protocol.
*
* These functions receive the \c context created in \c main(). This
diff --git a/src/openvpn/mudp.c b/src/openvpn/mudp.c
index 5af1081fc..7977ece5d 100644
--- a/src/openvpn/mudp.c
+++ b/src/openvpn/mudp.c
@@ -284,19 +284,8 @@ p2mp_iow_flags(const struct multi_context *m)
}
-/**/
-/**
- * Main event loop for OpenVPN in UDP server mode.
- * @ingroup eventloop
- *
- * This function implements OpenVPN's main event loop for UDP server mode.
- * At this time, OpenVPN does not yet support multithreading. This
- * function's name is therefore slightly misleading.
- *
- * @param top - Top-level context structure.
- */
-static void
-tunnel_server_udp_single_threaded(struct context *top)
+void
+tunnel_server_udp(struct context *top)
{
struct multi_context multi;
@@ -374,9 +363,3 @@ tunnel_server_udp_single_threaded(struct context *top)
close_instance(top);
}
-void
-tunnel_server_udp(struct context *top)
-{
-tunnel_server_udp_single_threaded(top);
-}
-
diff --git a/src/openvpn/mudp.h b/src/openvpn/mudp.h
index 460a768b3..340381e08 100644
--- a/src/openvpn/mudp.h
+++ b/src/openvpn/mudp.h
@@ -32,14 +32,13 @@ struct context;
struct multi_context;
-/**/
/**
- * Main event loop wrapper function for OpenVPN in UDP server mode.
+ * Main event loop for OpenVPN in UDP server mode.
* @ingroup eventloop
*
- * This function simply calls \c tunnel_server_udp_single_threaded().
+ * This function implements OpenVPN's main event loop for UDP server mode.
*
- * @param top - Top-level context structure.
+ * @param top - Top-level context structure.
*/
void tunnel_server_udp(struct context *top);
diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h
index 1063351d3..0ddaeb730 100644
--- a/src/openvpn/openvpn.h
+++ b/src/openvpn/openvpn.h
@@ -230,7 +230,7 @@ is_cas_pending(enum client_connect_status cas)
* \c SIGUSR1 restarts.
*
* This structure is initialized at the top of the \c
- * tunnel_point_to_point(), \c tunnel_server_udp_single_threaded(), and \c
+ * tunnel_point_to_point(), \c tunnel_server_udp(), and \c
* tunnel_server_tcp() functions. In other words, it is reset for every
* iteration of the \c main() function's inner \c SIGUSR1 loop.
*/
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 00/14] Various clean up patches
These are a number of patches that do various cleanups that I did as part of implementing DCO but are good on their own. Arne Schwabe (14): Remove code for aligning non-swapped compression Remove superflous ifdefs around enum like defines Rename tunnel_server_udp_single_threaded to tunnel_server_udp Add documentation on EVENT_READ/EVENT_WRITE constants Remove unused variable pass_config_info Remove pointless tun_adjust_frame_parameters function Remove unused field txqueuelen from struct tuntap Remove unused function tls_test_auth_deferred_interval Move is_proto function to the socket.h header Remove thread_mode field of multi_context Remove P2MP mode and check for gettimeofday Extract multi_assign_peer_id into its own function log file descriptor in more socket related error messages Remove do_init_socket_2 and do_init_socket_1 wrapper function doc/doxygen/doc_eventloop.h | 2 +- doc/doxygen/doc_tunnel_state.h | 2 +- src/compat/compat-gettimeofday.c | 2 +- src/openvpn/comp.h | 6 -- src/openvpn/error.c | 8 +- src/openvpn/event.c | 8 +- src/openvpn/forward.c| 26 +- src/openvpn/forward.h| 6 -- src/openvpn/helper.c | 3 - src/openvpn/init.c | 122 +- src/openvpn/manage.c | 4 - src/openvpn/mbuf.c | 3 - src/openvpn/mbuf.h | 3 - src/openvpn/mtcp.c | 7 +- src/openvpn/mtu.h| 6 -- src/openvpn/mudp.c | 45 +- src/openvpn/mudp.h | 7 +- src/openvpn/multi.c | 95 +++- src/openvpn/multi.h | 20 +++-- src/openvpn/openvpn.h| 25 +++--- src/openvpn/options.c| 55 ++-- src/openvpn/options.h| 49 ++- src/openvpn/otime.c | 4 - src/openvpn/pool.c | 4 - src/openvpn/pool.h | 3 - src/openvpn/push.c | 3 - src/openvpn/push.h | 3 - src/openvpn/pushlist.h | 4 +- src/openvpn/route.h | 2 - src/openvpn/shaper.c | 5 +- src/openvpn/shaper.h | 4 - src/openvpn/socket.c | 145 ++- src/openvpn/socket.h | 90 +-- src/openvpn/ssl.h| 11 --- src/openvpn/ssl_common.h | 4 - src/openvpn/syshead.h| 32 --- src/openvpn/tun.h| 13 --- 37 files changed, 234 insertions(+), 597 deletions(-) -- 2.30.1 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 10/14] Remove thread_mode field of multi_context
This is leftover of a never functional multi threaded openvpn
implementation attempt. It serves no purposes anymore.
Signed-off-by: Arne Schwabe
---
src/openvpn/mtcp.c | 2 +-
src/openvpn/mudp.c | 2 +-
src/openvpn/multi.c | 67 +++--
src/openvpn/multi.h | 10 +--
4 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/src/openvpn/mtcp.c b/src/openvpn/mtcp.c
index 7d2a69b99..babed29ef 100644
--- a/src/openvpn/mtcp.c
+++ b/src/openvpn/mtcp.c
@@ -789,7 +789,7 @@ tunnel_server_tcp(struct context *top)
}
/* initialize global multi_context object */
-multi_init(, top, true, MC_SINGLE_THREADED);
+multi_init(, top, true);
/* initialize our cloned top object */
multi_top_init(, top);
diff --git a/src/openvpn/mudp.c b/src/openvpn/mudp.c
index 7977ece5d..90e32a8ec 100644
--- a/src/openvpn/mudp.c
+++ b/src/openvpn/mudp.c
@@ -300,7 +300,7 @@ tunnel_server_udp(struct context *top)
}
/* initialize global multi_context object */
-multi_init(, top, false, MC_SINGLE_THREADED);
+multi_init(, top, false);
/* initialize our cloned top object */
multi_top_init(, top);
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f7e0f6805..9b4a3383f 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -290,7 +290,7 @@ int_compare_function(const void *key1, const void *key2)
* Main initialization function, init multi_context object.
*/
void
-multi_init(struct multi_context *m, struct context *t, bool tcp_mode, int
thread_mode)
+multi_init(struct multi_context *m, struct context *t, bool tcp_mode)
{
int dev = DEV_TYPE_UNDEF;
@@ -308,8 +308,6 @@ multi_init(struct multi_context *m, struct context *t, bool
tcp_mode, int thread
*/
CLEAR(*m);
-m->thread_mode = thread_mode;
-
/*
* Real address hash table (source port number is
* considered to be part of the address). Used
@@ -703,53 +701,44 @@ multi_close_instance(struct multi_context *m,
void
multi_uninit(struct multi_context *m)
{
-if (m->thread_mode & MC_WORK_THREAD)
-{
-multi_top_free(m);
-m->thread_mode = MC_UNDEF;
-}
-else if (m->thread_mode)
+if (m->hash)
{
-if (m->hash)
-{
-struct hash_iterator hi;
-struct hash_element *he;
+struct hash_iterator hi;
+struct hash_element *he;
-hash_iterator_init(m->iter, );
-while ((he = hash_iterator_next()))
-{
-struct multi_instance *mi = (struct multi_instance *)
he->value;
-mi->did_iter = false;
-multi_close_instance(m, mi, true);
-}
-hash_iterator_free();
+hash_iterator_init(m->iter, );
+while ((he = hash_iterator_next()))
+{
+struct multi_instance *mi = (struct multi_instance *) he->value;
+mi->did_iter = false;
+multi_close_instance(m, mi, true);
+}
+hash_iterator_free();
-multi_reap_all(m);
+multi_reap_all(m);
-hash_free(m->hash);
-hash_free(m->vhash);
-hash_free(m->iter);
+hash_free(m->hash);
+hash_free(m->vhash);
+hash_free(m->iter);
#ifdef ENABLE_MANAGEMENT
-hash_free(m->cid_hash);
+hash_free(m->cid_hash);
#endif
-m->hash = NULL;
+m->hash = NULL;
-free(m->instances);
+free(m->instances);
#ifdef ENABLE_ASYNC_PUSH
-hash_free(m->inotify_watchers);
-m->inotify_watchers = NULL;
+hash_free(m->inotify_watchers);
+m->inotify_watchers = NULL;
#endif
-schedule_free(m->schedule);
-mbuf_free(m->mbuf);
-ifconfig_pool_free(m->ifconfig_pool);
-frequency_limit_free(m->new_connection_limiter);
-multi_reap_free(m->reaper);
-mroute_helper_free(m->route_helper);
-multi_tcp_free(m->mtcp);
-m->thread_mode = MC_UNDEF;
-}
+schedule_free(m->schedule);
+mbuf_free(m->mbuf);
+ifconfig_pool_free(m->ifconfig_pool);
+frequency_limit_free(m->new_connection_limiter);
+multi_reap_free(m->reaper);
+mroute_helper_free(m->route_helper);
+multi_tcp_free(m->mtcp);
}
}
diff --git a/src/openvpn/multi.h b/src/openvpn/multi.h
index 7669508c3..b7078b711 100644
--- a/src/openvpn/multi.h
+++ b/src/openvpn/multi.h
@@ -150,14 +150,6 @@ struct multi_instance {
* server-mode.
*/
struct multi_context {
-#define MC_UNDEF 0
-#define MC_SINGLE_THREADED(1<<0)
-#define MC_MULTI_THREADED_MASTER (1<<1)
-#define MC_MULTI_THREADED_WORKER (1<<2)
-#define MC_MULTI_THREADED_SCHEDULER (1<<3)
-#define MC_WORK_THREAD
(MC_MULTI_THREADED_WORKER|MC_MULTI_THREADED_SCHEDULER)
-int thread_mode;
-
struct
[Openvpn-devel] [PATCH 11/14] Remove P2MP mode and check for gettimeofday
Using OpenVPN without P2MP support (pull, TLS) is unrealistic and
building a binary without it is not something we realistically want
to support anyway.
Signed-off-by: Arne Schwabe
---
src/compat/compat-gettimeofday.c | 2 +-
src/openvpn/forward.c| 23 ++---
src/openvpn/forward.h| 6
src/openvpn/helper.c | 3 --
src/openvpn/init.c | 29 +
src/openvpn/manage.c | 4 ---
src/openvpn/mbuf.c | 3 --
src/openvpn/mbuf.h | 3 --
src/openvpn/multi.c | 7
src/openvpn/openvpn.h| 7
src/openvpn/options.c| 55
src/openvpn/options.h| 49
src/openvpn/otime.c | 4 ---
src/openvpn/pool.c | 4 ---
src/openvpn/pool.h | 3 --
src/openvpn/push.c | 3 --
src/openvpn/push.h | 3 --
src/openvpn/pushlist.h | 4 +--
src/openvpn/route.h | 2 --
src/openvpn/shaper.c | 5 +--
src/openvpn/shaper.h | 4 ---
src/openvpn/syshead.h| 32 ---
22 files changed, 49 insertions(+), 206 deletions(-)
diff --git a/src/compat/compat-gettimeofday.c b/src/compat/compat-gettimeofday.c
index 117aee7d7..e63c8d7f8 100644
--- a/src/compat/compat-gettimeofday.c
+++ b/src/compat/compat-gettimeofday.c
@@ -93,7 +93,7 @@ gettimeofday(struct timeval *tv, void *tz)
{
/* We try to dampen out backtracks of less than backtrack_hold_seconds.
* Larger backtracks will be passed through and dealt with by the
- * TIME_BACKTRACK_PROTECTION code (if enabled) */
+ * TIME_BACKTRACK_PROTECTION code */
if (sec > last_sec - backtrack_hold_seconds)
{
sec = last_sec;
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 98caf6651..01f3f3b9b 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -189,8 +189,6 @@ check_tls_errors_nco(struct context *c)
register_signal(c, c->c2.tls_exit_signal, "tls-error"); /* SOFT-SIGUSR1 --
TLS error */
}
-#if P2MP
-
/*
* Handle incoming configuration
* messages on the control channel.
@@ -269,8 +267,6 @@ check_push_request(struct context *c)
event_timeout_modify_wakeup(>c2.push_request_interval,
PUSH_REQUEST_INTERVAL);
}
-#endif /* P2MP */
-
/*
* Things that need to happen immediately after connection initiation should
go here.
*
@@ -286,7 +282,6 @@ check_connection_established(struct context *c)
if (CONNECTION_ESTABLISHED(c))
{
-#if P2MP
/* if --pull was specified, send a push request to server */
if (c->c2.tls_multi && c->options.pull)
{
@@ -313,7 +308,6 @@ check_connection_established(struct context *c)
reset_coarse_timers(c);
}
else
-#endif /* if P2MP */
{
do_up(c, false, 0);
}
@@ -428,7 +422,6 @@ get_server_poll_remaining_time(struct event_timeout
*server_poll_timeout)
int remaining = event_timeout_remaining(server_poll_timeout);
return max_int(0, remaining);
}
-#if P2MP
void
check_server_poll_timeout(struct context *c)
@@ -466,8 +459,6 @@ check_scheduled_exit(struct context *c)
register_signal(c, c->c2.scheduled_exit_signal, "delayed-exit");
}
-#endif /* if P2MP */
-
/*
* Should we write timer-triggered status file.
*/
@@ -635,13 +626,12 @@ process_coarse_timers(struct context *c)
{
check_connection_established(c);
}
-#if P2MP
+
/* see if we should send a push_request (option --pull) */
if (event_timeout_trigger(>c2.push_request_interval, >c2.timeval,
ETT_DEFAULT))
{
check_push_request(c);
}
-#endif
#ifdef PLUGIN_PF
if (c->c2.pf.enabled
@@ -676,7 +666,6 @@ process_coarse_timers(struct context *c)
return;
}
-#if P2MP
if (c->c2.tls_multi)
{
if (c->options.ce.connect_timeout
@@ -697,7 +686,6 @@ process_coarse_timers(struct context *c)
return;
}
}
-#endif
/* Should we send an OCC_REQUEST message? */
check_send_occ_req(c);
@@ -1583,13 +1571,12 @@ process_outgoing_link(struct context *c)
* Let the traffic shaper know how many bytes
* we wrote.
*/
-#ifdef ENABLE_FEATURE_SHAPER
if (c->options.shaper)
{
shaper_wrote_bytes(>c2.shaper, BLEN(>c2.to_link)
+ datagram_overhead(c->options.ce.proto));
}
-#endif
+
/*
* Let the pinger know that we sent a packet.
*/
@@ -1843,14 +1830,12 @@ pre_select(struct context *c)
return;
}
-#if P2MP
/* check for incoming control messages on the control channel like
* push request/reply, or authentication failure and 2FA messages */
if
[Openvpn-devel] [PATCH 09/14] Move is_proto function to the socket.h header
These functions are small enough to be inlined and also avoids
dependency on socket.c from unit_tests using those functions.
Signed-off-by: Arne Schwabe
---
src/openvpn/socket.c | 36 ---
src/openvpn/socket.h | 50 +---
2 files changed, 38 insertions(+), 48 deletions(-)
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 0d9b793cd..6fed4b660 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -3101,42 +3101,6 @@ static const struct proto_names proto_names[] = {
{"tcp6","TCPv6", AF_INET6, PROTO_TCP},
};
-bool
-proto_is_net(int proto)
-{
-if (proto < 0 || proto >= PROTO_N)
-{
-ASSERT(0);
-}
-return proto != PROTO_NONE;
-}
-
-bool
-proto_is_dgram(int proto)
-{
-return proto_is_udp(proto);
-}
-
-bool
-proto_is_udp(int proto)
-{
-if (proto < 0 || proto >= PROTO_N)
-{
-ASSERT(0);
-}
-return proto == PROTO_UDP;
-}
-
-bool
-proto_is_tcp(int proto)
-{
-if (proto < 0 || proto >= PROTO_N)
-{
-ASSERT(0);
-}
-return proto == PROTO_TCP_CLIENT || proto == PROTO_TCP_SERVER;
-}
-
int
ascii2proto(const char *proto_name)
{
diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h
index 4099f6ea5..d58fda4d3 100644
--- a/src/openvpn/socket.h
+++ b/src/openvpn/socket.h
@@ -474,18 +474,6 @@ socket_descriptor_t socket_do_accept(socket_descriptor_t
sd,
struct link_socket_actual *act,
const bool nowait);
-/*
- * proto related
- */
-bool proto_is_net(int proto);
-
-bool proto_is_dgram(int proto);
-
-bool proto_is_udp(int proto);
-
-bool proto_is_tcp(int proto);
-
-
#if UNIX_SOCK_SUPPORT
socket_descriptor_t create_socket_unix(void);
@@ -572,6 +560,44 @@ enum proto_num {
PROTO_N
};
+static inline bool
+proto_is_net(int proto)
+{
+ASSERT(proto >= 0 && proto < PROTO_N);
+return proto != PROTO_NONE;
+}
+
+/**
+ * @brief Returns if the protocol being used is UDP
+ */
+static inline bool
+proto_is_udp(int proto)
+{
+ASSERT(proto >= 0 && proto < PROTO_N);
+return proto == PROTO_UDP;
+}
+
+/**
+ * @brief Return if the protocol is datagram (UDP)
+ *
+ */
+static inline bool
+proto_is_dgram(int proto)
+{
+return proto_is_udp(proto);
+}
+
+/**
+ * @brief returns if the proto is a TCP variant (tcp-server, tcp-client or
tcp)
+ */
+static inline bool
+proto_is_tcp(int proto)
+{
+ASSERT(proto >= 0 && proto < PROTO_N);
+return proto == PROTO_TCP_CLIENT || proto == PROTO_TCP_SERVER;
+}
+
+
int ascii2proto(const char *proto_name);
sa_family_t ascii2af(const char *proto_name);
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 08/14] Remove unused function tls_test_auth_deferred_interval
This function appears to completely unused and has not been touched
since 2008.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
index 8c8cbe028..300a70d35 100644
--- a/src/openvpn/ssl.h
+++ b/src/openvpn/ssl.h
@@ -530,17 +530,6 @@ tls_initial_packet_received(const struct tls_multi *multi)
return multi->n_sessions > 0;
}
-static inline bool
-tls_test_auth_deferred_interval(const struct tls_multi *multi)
-{
-if (multi)
-{
-const struct key_state *ks =
>session[TM_ACTIVE].key[KS_PRIMARY];
-return now < ks->auth_deferred_expire;
-}
-return false;
-}
-
static inline int
tls_test_payload_len(const struct tls_multi *multi)
{
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 05/14] Remove unused variable pass_config_info
Signed-off-by: Arne Schwabe --- src/openvpn/ssl_common.h | 4 1 file changed, 4 deletions(-) diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h index 4e1ff6c84..18bce403a 100644 --- a/src/openvpn/ssl_common.h +++ b/src/openvpn/ssl_common.h @@ -293,10 +293,6 @@ struct tls_options char *x509_username_field[2]; #endif -/* allow openvpn config info to be - * passed over control channel */ -bool pass_config_info; - /* struct crypto_option flags */ unsigned int crypto_flags; -- 2.30.1 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 07/14] Remove unused field txqueuelen from struct tuntap
The code uses tuntap->options.txqueuelen instead. Signed-off-by: Arne Schwabe --- src/openvpn/tun.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 7e8fb7647..60ebfdcba 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -165,9 +165,6 @@ struct tuntap char *actual_name; /* actual name of TUN/TAP dev, usually including unit number */ -/* number of TX buffers */ -int txqueuelen; - /* ifconfig parameters */ in_addr_t local; in_addr_t remote_netmask; -- 2.30.1 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 01/14] Remove code for aligning non-swapped compression
This is an optimisation for memory alignment for lzo. Compression is
deprecated so this optimisation is not very important anymore.
Furthermore it is conditionally compiled on !defined(ENABLE_LZ4), which
makes the code not compiled in by default anyway.
Signed-off-by: Arne Schwabe
---
src/openvpn/comp.h | 6 --
src/openvpn/init.c | 31 ---
src/openvpn/mtu.h | 6 --
3 files changed, 43 deletions(-)
diff --git a/src/openvpn/comp.h b/src/openvpn/comp.h
index 5c0322ca6..5c9d77fe1 100644
--- a/src/openvpn/comp.h
+++ b/src/openvpn/comp.h
@@ -198,11 +198,5 @@ comp_non_stub_enabled(const struct compress_options *info)
&& info->alg != COMP_ALG_UNDEF;
}
-static inline bool
-comp_unswapped_prefix(const struct compress_options *info)
-{
-return !(info->flags & COMP_F_SWAP);
-}
-
#endif /* USE_COMP */
#endif /* ifndef OPENVPN_COMP_H */
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 132d47e4e..1a6015452 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3082,37 +3082,6 @@ do_init_frame(struct context *c)
{
comp_add_to_extra_frame(>c2.frame);
-#if !defined(ENABLE_LZ4)
-/*
- * Compression usage affects buffer alignment when non-swapped algs
- * such as LZO is used.
- * Newer algs like LZ4 and comp-stub with COMP_F_SWAP don't need
- * any special alignment because of the control-byte swap approach.
- * LZO alignment (on the other hand) is problematic because
- * the presence of the control byte means that either the output of
- * decryption must be written to an unaligned buffer, or the input
- * to compression (or packet dispatch if packet is uncompressed)
- * must be read from an unaligned buffer.
- * This code tries to align the input to compression (or packet
- * dispatch if packet is uncompressed) at the cost of requiring
- * decryption output to be written to an unaligned buffer, so
- * it's more of a tradeoff than an optimal solution and we don't
- * include it when we are doing a modern build with LZ4.
- * Strictly speaking, on the server it would be better to execute
- * this code for every connection after we decide the compression
- * method, but currently the frame code doesn't appear to be
- * flexible enough for this, since the frame is already established
- * before it is known which compression options will be pushed.
- */
-if (comp_unswapped_prefix(>options.comp) && CIPHER_ENABLED(c))
-{
-frame_add_to_align_adjust(>c2.frame, COMP_PREFIX_LEN);
-frame_or_align_flags(>c2.frame,
- FRAME_HEADROOM_MARKER_FRAGMENT
- |FRAME_HEADROOM_MARKER_DECRYPT);
-}
-#endif
-
#ifdef ENABLE_FRAGMENT
comp_add_to_extra_frame(>c2.frame_fragment_omit); /* omit
compression frame delta from final frame_fragment */
#endif
diff --git a/src/openvpn/mtu.h b/src/openvpn/mtu.h
index 0c8bdf8ba..92cbe1874 100644
--- a/src/openvpn/mtu.h
+++ b/src/openvpn/mtu.h
@@ -300,12 +300,6 @@ frame_add_to_extra_buffer(struct frame *frame, const int
increment)
frame->extra_buffer += increment;
}
-static inline void
-frame_add_to_align_adjust(struct frame *frame, const int increment)
-{
-frame->align_adjust += increment;
-}
-
static inline void
frame_align_to_extra_frame(struct frame *frame)
{
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Am 01.04.21 um 14:37 schrieb Gert Doering: > Hi, > > On Thu, Apr 01, 2021 at 02:16:25PM +0200, Antonio Quartulli wrote: >>> (Of course it makes lots of sense to defer this to iptables etc. on >>> all platforms that have DCO *and* a reasonable firewall layer... dco-win >>> will be interesting) >> >> Features that are not compatible with DCO are being documented in the >> code as we go. >> >> If you try to explicitly use one of those with DCO, openvpn2 will log a >> big warning and will tell you that it is switching to non-DCO mode to >> make sure your connection can work. > > Which is actually interesting for mssfix, as that is "on by default", > so "all configs are incompatible with DCO", by that definition :-) Yes. With DCO we currently discovering that the OpenVPN way of doing things with MTU set to 1500, doing mssfix and hoping that this will clamp everything to 1450-overhead, while working quite well has a lot of problems compared to just setting a proper MTU in the first case. Currently setting tun-mtu 1400 manually workaround these problems but we need to figure out a good way to solve this MTU mess. The current working idea is to allow MTU 1500 on receive but use a correct MTU on receive and on the interface (at least on platforms where you can receive larger packets than MTU). But currently we are just on the "we are aware of it" stage. And too busy with other things to actually tackle that too right now. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Hi, On 01/04/2021 14:37, Gert Doering wrote: > Which is actually interesting for mssfix, as that is "on by default", > so "all configs are incompatible with DCO", by that definition :-) hehe Arne can confirm, but I think defaults are adapted to what DCO expects, so mssfix is just disabled by default when DCO is on. I can already hear the arguments that this will create some confusion, but it will be documented :-) It's our chance to get rid of some "legacy". > >> However, we will definitely make some larger doc explaining what we >> decided that DCO should not do and what are possible alternatives. > > *like* > > gert > Regards, -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v2] Remove deprecated option '--keysize'
This option has been deprecated in OpenVPN 2.4 and the ciphers that allow
using this option fall all into the SWEET32 category of ciphers with
64 bit block size.
Patch V2: Remove superflous check in OpenSSL codepath to check keysize
Signed-off-by: Arne Schwabe
---
config-msvc.h| 1 -
configure.ac | 2 +-
src/openvpn/crypto.c | 6 +-
src/openvpn/crypto.h | 4 +---
src/openvpn/crypto_openssl.c | 12 ++--
src/openvpn/init.c | 5 ++---
src/openvpn/options.c| 33 ++---
src/openvpn/options.h| 2 --
src/openvpn/ssl.c| 7 +--
9 files changed, 10 insertions(+), 62 deletions(-)
diff --git a/config-msvc.h b/config-msvc.h
index 4db9efae2..aea2628be 100644
--- a/config-msvc.h
+++ b/config-msvc.h
@@ -48,7 +48,6 @@
#define HAVE_CHDIR 1
#define HAVE_CHSIZE 1
#define HAVE_CTIME 1
-#define HAVE_EVP_CIPHER_CTX_SET_KEY_LENGTH 1
#define HAVE_IN_PKTINFO 1
#define HAVE_MEMSET 1
#define HAVE_PUTENV 1
diff --git a/configure.ac b/configure.ac
index 3cb9fc2fc..7bc6c7b90 100644
--- a/configure.ac
+++ b/configure.ac
@@ -878,7 +878,7 @@ if test "${with_crypto_library}" = "openssl"; then
)
fi
- AC_CHECK_FUNCS([SSL_CTX_new EVP_CIPHER_CTX_set_key_length],
+ AC_CHECK_FUNCS([SSL_CTX_new],
,
[AC_MSG_ERROR([openssl check failed])]
)
diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index 3a0bfbec4..b042514bf 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -739,7 +739,7 @@ warn_insecure_key_type(const char *ciphername, const
cipher_kt_t *cipher)
*/
void
init_key_type(struct key_type *kt, const char *ciphername,
- const char *authname, int keysize, bool tls_mode, bool warn)
+ const char *authname, bool tls_mode, bool warn)
{
bool aead_cipher = false;
@@ -756,10 +756,6 @@ init_key_type(struct key_type *kt, const char *ciphername,
}
kt->cipher_length = cipher_kt_key_size(kt->cipher);
-if (keysize > 0 && keysize <= MAX_CIPHER_KEY_LENGTH)
-{
-kt->cipher_length = keysize;
-}
/* check legal cipher mode */
aead_cipher = cipher_kt_mode_aead(kt->cipher);
diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h
index 1ad669ce1..b8128c7f1 100644
--- a/src/openvpn/crypto.h
+++ b/src/openvpn/crypto.h
@@ -301,14 +301,12 @@ int read_key(struct key *key, const struct key_type *kt,
struct buffer *buf);
* @param kt The struct key_type to initialize
* @param ciphername The name of the cipher to use
* @param authnameThe name of the HMAC digest to use
- * @param keysize The length of the cipher key to use, in bytes. Only
valid
- *for ciphers that support variable length keys.
* @param tls_modeSpecifies whether we are running in TLS mode, which
allows
*more ciphers than static key mode.
* @param warnPrint warnings when null cipher / auth is used.
*/
void init_key_type(struct key_type *kt, const char *ciphername,
- const char *authname, int keysize, bool tls_mode, bool
warn);
+ const char *authname, bool tls_mode, bool warn);
/*
* Key context functions
diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
index 573beaed7..f3e86863e 100644
--- a/src/openvpn/crypto_openssl.c
+++ b/src/openvpn/crypto_openssl.c
@@ -292,10 +292,8 @@ show_available_ciphers(void)
#ifndef ENABLE_SMALL
printf("The following ciphers and cipher modes are available for use\n"
"with " PACKAGE_NAME ". Each cipher shown below may be used as a\n"
- "parameter to the --data-ciphers (or --cipher) option. The\n"
- "default key size is shown as well as whether or not it can be\n"
- "changed with the --keysize directive. Using a GCM or CBC mode\n"
- "is recommended. In static key mode only CBC mode is
allowed.\n\n");
+ "parameter to the --data-ciphers (or --cipher) option. In static \n"
+ "key mode only CBC mode is allowed.\n\n");
#endif
for (nid = 0; nid < 1; ++nid)
@@ -776,12 +774,6 @@ cipher_ctx_init(EVP_CIPHER_CTX *ctx, const uint8_t *key,
int key_len,
{
crypto_msg(M_FATAL, "EVP cipher init #1");
}
-#ifdef HAVE_EVP_CIPHER_CTX_SET_KEY_LENGTH
-if (!EVP_CIPHER_CTX_set_key_length(ctx, key_len))
-{
-crypto_msg(M_FATAL, "EVP set key size");
-}
-#endif
if (!EVP_CipherInit_ex(ctx, NULL, NULL, key, NULL, enc))
{
crypto_msg(M_FATAL, "EVP cipher init #2");
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 132d47e4e..336da9414 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2599,7 +2599,7 @@ do_init_crypto_static(struct context *c, const unsigned
int flags)
{
/* Get cipher & hash
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Hi, On Thu, Apr 01, 2021 at 02:16:25PM +0200, Antonio Quartulli wrote: > > (Of course it makes lots of sense to defer this to iptables etc. on > > all platforms that have DCO *and* a reasonable firewall layer... dco-win > > will be interesting) > > Features that are not compatible with DCO are being documented in the > code as we go. > > If you try to explicitly use one of those with DCO, openvpn2 will log a > big warning and will tell you that it is switching to non-DCO mode to > make sure your connection can work. Which is actually interesting for mssfix, as that is "on by default", so "all configs are incompatible with DCO", by that definition :-) > However, we will definitely make some larger doc explaining what we > decided that DCO should not do and what are possible alternatives. *like* gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Hi, On 01/04/2021 14:10, Gert Doering wrote: > Hi, > > On Thu, Apr 01, 2021 at 12:47:46PM +0200, Arne Schwabe wrote: >> In your dco to dco setup you probably >> don't have mssfix on either side unless you explicitly added iptables >> rules for that. > > Ah, this is interesting and needs to be documented - "if you want feature > , , together with DCO, it needs to be done in iptables". > > (Of course it makes lots of sense to defer this to iptables etc. on > all platforms that have DCO *and* a reasonable firewall layer... dco-win > will be interesting) Features that are not compatible with DCO are being documented in the code as we go. If you try to explicitly use one of those with DCO, openvpn2 will log a big warning and will tell you that it is switching to non-DCO mode to make sure your connection can work. However, we will definitely make some larger doc explaining what we decided that DCO should not do and what are possible alternatives. Regards, -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Hi, On Thu, Apr 01, 2021 at 12:47:46PM +0200, Arne Schwabe wrote: > In your dco to dco setup you probably > don't have mssfix on either side unless you explicitly added iptables > rules for that. Ah, this is interesting and needs to be documented - "if you want feature , , together with DCO, it needs to be done in iptables". (Of course it makes lots of sense to defer this to iptables etc. on all platforms that have DCO *and* a reasonable firewall layer... dco-win will be interesting) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v3] Always disable TLS renegotiations
Renegotiations have been troublesome in the past and also the recent OpenSSL
security problem (CVE-2021-3449) is only exploitable if TLS renegotiation
is enabled.
mbed TLS disables it by default and says in the documentation:
Warning: It is recommended to always disable renegotation unless you know you
need it and you know what you're doing. In the past, there have been
several issues associated with renegotiation or a poor understanding of
its properties.
TLS renegotiation can be used to restart a session with diffferent
parameters (e.g. now with client certs). This somethign that OpenVPN does
not use.
For OpenSSL 1.0.2 the workaround to disable renegotiation is rather
cumbersome. So we keep this to 1.1.1 only since 1.0.2 is on its way to
deprecation anyway.
Furthermore because of all these problems, also TLS 1.3 completely
drops support for renegotiations.
Patch V2: Improve commments and commit message
Patch V3: Only disable renegotiation where the SSL_OP_NO_RENEGOTIATION
define is available. LibreSSL, wolfSSL and OpenSSL 1.0.2 are
lacking this macro.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl_mbedtls.c | 4
src/openvpn/ssl_openssl.c | 6 ++
2 files changed, 10 insertions(+)
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 4626e9838..8917fb188 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -1086,6 +1086,10 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
{
mbedtls_ssl_conf_curves(ks_ssl->ssl_config, ssl_ctx->groups);
}
+/* Disable TLS renegotiations. OpenVPN's renegotiation creates new SSL
+ * session and does not depend on this feature. And TLS renegotiations have
+ * been problematic in the past */
+mbedtls_ssl_conf_renegotiation(ks_ssl->ssl_config,
MBEDTLS_SSL_RENEGOTIATION_DISABLED);
/* Disable record splitting (for now). OpenVPN assumes records are sent
* unfragmented, and changing that will require thorough review and
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index b85f95be1..cb8ac7727 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -320,6 +320,12 @@ tls_ctx_set_options(struct tls_root_ctx *ctx, unsigned int
ssl_flags)
sslopt |= SSL_OP_CIPHER_SERVER_PREFERENCE;
#endif
sslopt |= SSL_OP_NO_COMPRESSION;
+/* Disable TLS renegotiations. OpenVPN's renegotiation creates new SSL
+ * session and does not depend on this feature. And TLS renegotiations have
+ * been problematic in the past */
+#ifdef SSL_OP_NO_RENEGOTIATION
+sslopt |= SSL_OP_NO_RENEGOTIATION;
+#endif
SSL_CTX_set_options(ctx->ctx, sslopt);
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v3] Always disable TLS renegotiations
Renegotiations have been troublesome in the past and also the recent OpenSSL
security problem (CVE-2021-3449) is only exploitable if TLS renegotiation
is enabled.
mbed TLS disables it by default and says in the documentation:
Warning: It is recommended to always disable renegotation unless you know you
need it and you know what you're doing. In the past, there have been
several issues associated with renegotiation or a poor understanding of
its properties.
TLS renegotiation can be used to restart a session with diffferent
parameters (e.g. now with client certs). This somethign that OpenVPN does
not use.
For OpenSSL 1.0.2 the workaround to disable renegotiation is rather
cumbersome. So we keep this to 1.1.1 only since 1.0.2 is on its way to
deprecation anyway.
Furthermore because of all these problems, also TLS 1.3 completely
drops support for renegotiations.
Patch V2: Improve commments and commit message
Patch V3: Only disable renegotiation where the SSL_OP_NO_RENEGOTIATION
define is available. LibreSSL, wolfSSL and OpenSSL 1.0.2 are
lacking this macro.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl_mbedtls.c | 4
src/openvpn/ssl_openssl.c | 4
2 files changed, 8 insertions(+)
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 4626e9838..8917fb188 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -1086,6 +1086,10 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
{
mbedtls_ssl_conf_curves(ks_ssl->ssl_config, ssl_ctx->groups);
}
+/* Disable TLS renegotiations. OpenVPN's renegotiation creates new SSL
+ * session and does not depend on this feature. And TLS renegotiations have
+ * been problematic in the past */
+mbedtls_ssl_conf_renegotiation(ks_ssl->ssl_config,
MBEDTLS_SSL_RENEGOTIATION_DISABLED);
/* Disable record splitting (for now). OpenVPN assumes records are sent
* unfragmented, and changing that will require thorough review and
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index b85f95be1..1f14b5d2c 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -320,6 +320,10 @@ tls_ctx_set_options(struct tls_root_ctx *ctx, unsigned int
ssl_flags)
sslopt |= SSL_OP_CIPHER_SERVER_PREFERENCE;
#endif
sslopt |= SSL_OP_NO_COMPRESSION;
+/* Disable TLS renegotiations. OpenVPN's renegotiation creates new SSL
+ * session and does not depend on this feature. And TLS renegotiations have
+ * been problematic in the past */
+sslopt |= SSL_OP_NO_RENEGOTIATION;
SSL_CTX_set_options(ctx->ctx, sslopt);
--
2.30.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Am 01.04.21 um 04:38 schrieb Tony He: > Hi Antonio, Arne, > > According to the dump, this issue is caused by fragment. If I set > link-mtu to 1472 in the condition of encryption "none", it's gone. > I also can reproduce the fragment in my Linux x86-64 PC and Linux VM . > They use kernel 5.4. Fragment affects the performance > in the low-end devices. It also consumes more CPU resource in low-end > and high-end devices. If I'm not mistaken, we don't need > to set link-mtu without dco. Is this a bug? Can you reproduce? Do I > still need to upload my dump? If so, maybe I need to provide a link. Yes that is expected. Use tun-mtu 1400. The mtu 1500 leading to fragmentation is a longstanding issue but ist almost entirely masked by mssfix being enabled by default. In your dco to dco setup you probably don't have mssfix on either side unless you explicitly added iptables rules for that. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/1] reliable: retransmit if 3 follow-up ACKs are received
Am 31.03.21 um 20:03 schrieb Max Fillinger: > From: Steffan Karger > > To improve the control channel performance under packet loss conditions, > add a more aggressive retransmit policy similar to what many TCP > implementations do: retransmit a packet if the ACK timeout expires (like > we already do), *or* if three ACKs for follow-up packets are received. > > The rationale behind this is that if follow-up packets *are* received, the > connection is apparently functional and we should be able to retransmit > immediately. This significantly improves performance for connections with > low (up to a few percent) packet loss. This is a reasonable approach and thanks for adding the comments. Acked-By: Arne Schwabe ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Get rid of last PLUGIN_DEF_AUTH #ifdef
Patch has been applied to the master branch. commit 997b006a266145c2797f7625eccb6f3623b7a59c Author: Gert Doering Date: Thu Apr 1 10:29:34 2021 +0200 Get rid of last PLUGIN_DEF_AUTH #ifdef Signed-off-by: Gert Doering Acked-by: Antonio Quartulli Message-Id: <20210401082934.29922-1-g...@greenie.muc.de> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21933.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Get rid of last PLUGIN_DEF_AUTH #ifdef
Hi, On 01/04/2021 10:29, Gert Doering wrote: > Commit 99d217b200 attempted to get rid of all #ifdef related to > --disable-def-auth but one of them managed to hide. Remove. > > The effect of this is that the "openvpn_acf_...tmp" files get not > removed after when an async auth plugin is in use. This is can > get very annoying on a busy server. > > Trac: #1186 > > Signed-off-by: Gert Doering nice catch :-) Another chapter for "why ifdefs can be problematic..even after we have tried to get rid of them". Compile tested on my CI and tested in a setup not having def-auth in use to make sure it wouldn't create side effects. Acked-by: Antonio Quartulli -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Get rid of last PLUGIN_DEF_AUTH #ifdef
Commit 99d217b200 attempted to get rid of all #ifdef related to
--disable-def-auth but one of them managed to hide. Remove.
The effect of this is that the "openvpn_acf_...tmp" files get not
removed after when an async auth plugin is in use. This is can
get very annoying on a busy server.
Trac: #1186
Signed-off-by: Gert Doering
---
src/openvpn/ssl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 893e5753..08222b5e 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -992,9 +992,7 @@ key_state_free(struct key_state *ks, bool clear)
packet_id_free(>crypto_options.packet_id);
-#ifdef PLUGIN_DEF_AUTH
key_state_rm_auth_control_files(ks);
-#endif
if (clear)
{
--
2.26.2
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Add LZ4 prerequisite building.
Hi,
On Mon, Mar 22, 2021 at 09:43:31AM +0100, Gert Doering wrote:
> commit 24596b258aa3a removed the bundled compat-lz4 from OpenVPN, thus
> breaking windows/nsis builds with default config ("--enable-lz4").
>
> Add download URLs and build invocation. Since LZ4 has no "configure"
> script, we pass the appropriate CC=/LD=/WINDRES= statement to "make".
>
> Only static library is installed, since static linking is easier here
> than to extend NSIS to bundle lz4.dll (+ whatever else is needed).
Just for the record. Samuli has turned this into a PR for openvpn-build,
https://github.com/OpenVPN/openvpn-build/pull/210
which got tested & ACKed by Lev and just merged by me.
So closing this on patchwork as "Accepted".
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] ovpn-dco: ovpn-cli: properly set socket options
Thanks!
Your patch has been applied with commit id:
0048aac81c3e4dc3046121a7124da77233656e99
Regards,
On 01/04/2021 08:44, Tony He wrote:
> Actully We can not set two options at the same time.
> Old code:
>
> setsockopt(s, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, , sizeof(opt))
>
> If you use strace to trace sys call, you will find only SO_REUSEPORT is
> set:
>> setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
>
> This is because SD_REUSEADDR is 2(0x0010) and SR_REUSEPORT is 15(0x)
> defined in
> /usr/include/asm-generic/socket.h in X86-64 platform.
>
> We need to set them one by one. In other platforms, if you set mutli
> options at the same time, you may encounter error "setsockopt: Protocol
> not available". Refer to
> https://stackoverflow.com/questions/58599070/socket-programming-setsockopt-protocol-not-available
>
> Signed-off-by: Tony He
> ---
> tests/ovpn-cli.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/tests/ovpn-cli.c b/tests/ovpn-cli.c
> index c1cf3b4..68d28b4 100644
> --- a/tests/ovpn-cli.c
> +++ b/tests/ovpn-cli.c
> @@ -426,9 +426,14 @@ static int ovpn_socket(struct ovpn_ctx *ctx, sa_family_t
> family, int proto)
> }
>
> int opt = 1;
> - ret = setsockopt(s, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, ,
> sizeof(opt));
> + ret = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, , sizeof(opt));
> if (ret < 0) {
> - perror("setsockopt");
> + perror("setsockopt for SO_REUSEADDR");
> + return ret;
> + }
> + ret = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, , sizeof(opt));
> + if (ret < 0) {
> + perror("setsockopt for SO_REUSEPORT");
> return ret;
> }
>
>
--
Antonio Quartulli
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
On 01/04/2021 09:07, Antonio Quartulli wrote: > Tony, in the meantime, setting the link-mtu to something lower than 1500 > is the proper workaround. Sorry I take this last sentence back. What I was talking all time long was the "tun-mtu". To fix the MTU issue when there is encapsulation, it's the tun-mtu that should be reduced (so that it can fit in the link-mtu after adding the protocol overhead). So the proper workaround should be to reduce the tun-mtu and avoid the default of 1500. Regards, -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Hi, Thanks for providing the info. On 01/04/2021 09:01, Tony He wrote: > % ifconfig ovpn-dco0 > ovpn-dco0: flags=81 mtu 1500 > % ifconfig ovpn-dco0 > ovpn-dco0: flags=81 mtu 1500 These values are not what ovpn-dco would set by default. > log from openvpn client: > 2021-04-01 14:57:31 net_iface_mtu_set: mtu 1500 for ovpn-dco0 Mhh, I presume the openvpn2 client still sets 1500 MTU as default, while it should just leave the MTU value alone when no link-mtu was specified by the user. Arne, I presume this is a change that could be applied to your dco branch? Tony, in the meantime, setting the link-mtu to something lower than 1500 is the proper workaround. Thanks. Regards, -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
sorry, update transport interface. % ifconfig enx00e04c680a44 enx00e04c680a44: flags=4163 mtu 1500 inet 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::ec9b:2258:82ec:3cdb prefixlen 64 scopeid 0x20 ether 00:e0:4c:68:0a:44 txqueuelen 1000 (Ethernet) RX packets 10365932 bytes 6963820421 (6.9 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 11883693 bytes 11887431595 (11.8 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Tony He 于2021年4月1日周四 下午3:01写道： > > > Antonio Quartulli 于2021年4月1日周四 下午2:35写道： > >> Hi Tony, >> >> On 01/04/2021 04:38, Tony He wrote: >> > Hi Antonio, Arne, >> > >> > According to the dump, this issue is caused by fragment. If I set >> > link-mtu to 1472 in the condition of encryption "none", it's gone. >> > I also can reproduce the fragment in my Linux x86-64 PC and Linux VM . >> > They use kernel 5.4. Fragment affects the performance >> > in the low-end devices. It also consumes more CPU resource in low-end >> > and high-end devices. If I'm not mistaken, we don't need >> > to set link-mtu without dco. Is this a bug? Can you reproduce? Do I >> > still need to upload my dump? If so, maybe I need to provide a link. >> >> You told us what you did to fix, but you haven't fully explained what >> the "broken setup" is. We don't have your configs, so we can't say what >> is creating the issue in your scenario. >> > server config: > root@OpenWrt:/tmp# cat openvpn-sample_server-fragment.conf > data-ciphers none > auth none > topology subnet > persist-key > persist-tun > ca /etc/luci-uploads/cbid.openvpn.sample_server.ca > cert /etc/luci-uploads/cbid.openvpn.sample_server.cert > dev tun > dh /etc/luci-uploads/cbid.openvpn.sample_server.dh > ifconfig-pool-persist /tmp/ipp.txt > keepalive 10 120 > key /etc/luci-uploads/cbid.openvpn.sample_server.key > port 1194 > proto udp > server 10.8.0.0 255.255.255.0 > status /tmp/openvpn-status.log > verb 3 > > client config: > % cat client-framgment.conf > auth none > client > dev tun > proto udp > remote 192.168.1.1 1194 > resolv-retry infinite > nobind > persist-key > persist-tun > ca ca.crt > cert client.crt > key client.key > data-ciphers none > verb 2 > writepid /var/run/openvpn.pid > > >> What is the MTU on the DCO and on the transport interfaces when the >> problem shows us? >> > % ifconfig ovpn-dco0 > ovpn-dco0: flags=81 mtu 1500 > inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2 > inet6 fe80::3559:b6c1:3fc3:b8cb prefixlen 64 scopeid 0x20 > unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen > 1000 (UNSPEC) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 1 bytes 134 (134.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > % ifconfig ovpn-dco0 > ovpn-dco0: flags=81 mtu 1500 > inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2 > inet6 fe80::3559:b6c1:3fc3:b8cb prefixlen 64 scopeid 0x20 > unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen > 1000 (UNSPEC) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 1 bytes 134 (134.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > log from openvpn client: > 2021-04-01 14:57:31 net_iface_mtu_set: mtu 1500 for ovpn-dco0 > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Antonio Quartulli 于2021年4月1日周四 下午2:35写道： > Hi Tony, > > On 01/04/2021 04:38, Tony He wrote: > > Hi Antonio, Arne, > > > > According to the dump, this issue is caused by fragment. If I set > > link-mtu to 1472 in the condition of encryption "none", it's gone. > > I also can reproduce the fragment in my Linux x86-64 PC and Linux VM . > > They use kernel 5.4. Fragment affects the performance > > in the low-end devices. It also consumes more CPU resource in low-end > > and high-end devices. If I'm not mistaken, we don't need > > to set link-mtu without dco. Is this a bug? Can you reproduce? Do I > > still need to upload my dump? If so, maybe I need to provide a link. > > You told us what you did to fix, but you haven't fully explained what > the "broken setup" is. We don't have your configs, so we can't say what > is creating the issue in your scenario. > server config: root@OpenWrt:/tmp# cat openvpn-sample_server-fragment.conf data-ciphers none auth none topology subnet persist-key persist-tun ca /etc/luci-uploads/cbid.openvpn.sample_server.ca cert /etc/luci-uploads/cbid.openvpn.sample_server.cert dev tun dh /etc/luci-uploads/cbid.openvpn.sample_server.dh ifconfig-pool-persist /tmp/ipp.txt keepalive 10 120 key /etc/luci-uploads/cbid.openvpn.sample_server.key port 1194 proto udp server 10.8.0.0 255.255.255.0 status /tmp/openvpn-status.log verb 3 client config: % cat client-framgment.conf auth none client dev tun proto udp remote 192.168.1.1 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client.crt key client.key data-ciphers none verb 2 writepid /var/run/openvpn.pid > What is the MTU on the DCO and on the transport interfaces when the > problem shows us? > % ifconfig ovpn-dco0 ovpn-dco0: flags=81 mtu 1500 inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2 inet6 fe80::3559:b6c1:3fc3:b8cb prefixlen 64 scopeid 0x20 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1 bytes 134 (134.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 % ifconfig ovpn-dco0 ovpn-dco0: flags=81 mtu 1500 inet 10.8.0.2 netmask 255.255.255.0 destination 10.8.0.2 inet6 fe80::3559:b6c1:3fc3:b8cb prefixlen 64 scopeid 0x20 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1 bytes 134 (134.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 log from openvpn client: 2021-04-01 14:57:31 net_iface_mtu_set: mtu 1500 for ovpn-dco0 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] ovpn-dco: ovpn-cli: properly set socket options
Actully We can not set two options at the same time.
Old code:
setsockopt(s, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, , sizeof(opt))
If you use strace to trace sys call, you will find only SO_REUSEPORT is
set:
>setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
This is because SD_REUSEADDR is 2(0x0010) and SR_REUSEPORT is 15(0x)
defined in
/usr/include/asm-generic/socket.h in X86-64 platform.
We need to set them one by one. In other platforms, if you set mutli
options at the same time, you may encounter error "setsockopt: Protocol
not available". Refer to
https://stackoverflow.com/questions/58599070/socket-programming-setsockopt-protocol-not-available
Signed-off-by: Tony He
---
tests/ovpn-cli.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tests/ovpn-cli.c b/tests/ovpn-cli.c
index c1cf3b4..68d28b4 100644
--- a/tests/ovpn-cli.c
+++ b/tests/ovpn-cli.c
@@ -426,9 +426,14 @@ static int ovpn_socket(struct ovpn_ctx *ctx, sa_family_t
family, int proto)
}
int opt = 1;
- ret = setsockopt(s, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, ,
sizeof(opt));
+ ret = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, , sizeof(opt));
if (ret < 0) {
- perror("setsockopt");
+ perror("setsockopt for SO_REUSEADDR");
+ return ret;
+ }
+ ret = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, , sizeof(opt));
+ if (ret < 0) {
+ perror("setsockopt for SO_REUSEPORT");
return ret;
}
--
2.17.1
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection
Hi Tony, On 01/04/2021 04:38, Tony He wrote: > Hi Antonio, Arne, > > According to the dump, this issue is caused by fragment. If I set > link-mtu to 1472 in the condition of encryption "none", it's gone. > I also can reproduce the fragment in my Linux x86-64 PC and Linux VM . > They use kernel 5.4. Fragment affects the performance > in the low-end devices. It also consumes more CPU resource in low-end > and high-end devices. If I'm not mistaken, we don't need > to set link-mtu without dco. Is this a bug? Can you reproduce? Do I > still need to upload my dump? If so, maybe I need to provide a link. You told us what you did to fix, but you haven't fully explained what the "broken setup" is. We don't have your configs, so we can't say what is creating the issue in your scenario. What is the MTU on the DCO and on the transport interfaces when the problem shows us? DCO should automatically come up with a working MTU, unless instructed to do differently or unless the transport interface has non standard MTU. Regards, -- Antonio Quartulli ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 0/1] reliable: retransmit if 3 follow-up ACKs are received
> Hi, > > On Thu, Apr 01, 2021 at 08:20:48AM +0200, Simon Matter wrote: >> > Yes. But it only affects the control channel. For data channel we >> never >> > do retransmits. >> >> OK, but it still could help in case of things like VoIP UDP over OpenVPN >> UDP with lots of small packets going over the link with low package >> loss? > > No, because VoIP-over-OpenVPN would be "data channel". > > It would help with "control channel handshake takes very long due to > packet > loss". > > There's a different patchset floating around (I think it's a PR, actually) > that promises to add data-channel redundancy and being able to recover > some > amount of packet loss without retransmit. Which I find very interesting, > but this has not been followed up due to "it's complex and nobody has > time" > reasons. > > gert Thanks for the explanation! Simon ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 0/1] reliable: retransmit if 3 follow-up ACKs are received
Hi, On Thu, Apr 01, 2021 at 08:20:48AM +0200, Simon Matter wrote: > > Yes. But it only affects the control channel. For data channel we never > > do retransmits. > > OK, but it still could help in case of things like VoIP UDP over OpenVPN > UDP with lots of small packets going over the link with low package loss? No, because VoIP-over-OpenVPN would be "data channel". It would help with "control channel handshake takes very long due to packet loss". There's a different patchset floating around (I think it's a PR, actually) that promises to add data-channel redundancy and being able to recover some amount of packet loss without retransmit. Which I find very interesting, but this has not been followed up due to "it's complex and nobody has time" reasons. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Stop using deprecated getpass()
Your patch has been applied to the master branch. I have compile-tested this across all our supported platforms to be sure that we do not hit undefined symbols (like, "ECHOK", which was unknown to me before) - but hat is all OK. I have given it minimal testing on my corp VPN profile on Linux (works). Interesting enough, my corp VPN "password" is 2FA + PIN, which makes it longer than 8 characters :-) - I've never used that from a Solaris *client*, otherwise I might have noticed the issue myself... Thanks for your work! commit 76ccc62d4884721b6ecc11078abef747ea60d8d0 Author: Tõivo Leedjärv Date: Sun Mar 28 17:11:51 2021 + Stop using deprecated getpass() Signed-off-by: Tõivo Leedjärv Acked-by: Antonio Quartulli Message-Id: <20210328171151.12056-1-toi...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21889.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 0/1] reliable: retransmit if 3 follow-up ACKs are received
> > Am 31.03.2021 um 21:39 schrieb Simon Matter: >>> This is my second attempt at sending this patch, this time without >>> mixing up commit message and cover letter, and from an account that >>> (I hope) doesn't hate mailing lists. >>> >>> This patch changes reliable_send() to resend a packet if at least three >>> later packets have been ACKed. This improves performance when there are >>> small amounts of packet loss. >>> >>> The patch was originally written by Steffan Karger for OpenVPN-NL. >>> I added some comments as suggested by Arne Schwabe. >>> >>> Steffan Karger (1): >>>reliable: retransmit if 3 follow-up ACKs are received >>> >> Hi Max, >> >> Just a shy question, am I right that this will work with UDP >> connections? >> >> If so then I'm interested to test it. > > Yes. But it only affects the control channel. For data channel we never > do retransmits. OK, but it still could help in case of things like VoIP UDP over OpenVPN UDP with lots of small packets going over the link with low package loss? Simon ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
