Re: [Openvpn-devel] [PATCH 20/28] Change reliable_get_buf_sequenced to reliable_get_entry_sequenced

* buffer. * - * @return A pointer to the buffer of the entry with the next - * sequential key ID. If no such entry is present, this function - * returns NULL. + * @return A pointer to the entry with the next sequential key ID. + * If no such entry is present, this functio

[Openvpn-devel] [PATCH v2] Implement stateless, HMAC basedsesssion id three way handshake

OpenVPN currently has a bit of a weakness in its early three way handshake A single client reset packet (first packet of the handshake) will - trigger creating session on the server side leading to poential ressource exhaustian - make the server respond with 3 answers trying to get an ACK

[Openvpn-devel] [PATCH v2] Implement constructing a control channel reset client as standalone fucntion

This implement creating a reset packet without needing to setup a full control session. Patch v2: fix unit test not working without further commits Signed-off-by: Arne Schwabe --- src/openvpn/packet_id.h | 15 src/openvpn/ssl.h | 6 -- src/openvpn/ssl_pkt.c

Re: [Openvpn-devel] [PATCH 17/28] Implement constructing a control channel reset client as standalone fucntion

Hi, On Wed, Apr 27, 2022 at 06:43:31PM +0200, Gert Doering wrote: > [ ERROR ] --- ASSERT: buf_write(&buf, &net_pid, sizeof(net_pid)) > [ LINE ] --- ../../../../openvpn/src/openvpn/ssl_pkt.c:425: error: > Failure! > [ FAILED ] test_generate_reset_packet_tls_auth It needs this hunk from 1

Re: [Openvpn-devel] [PATCH 17/28] Implement constructing a control channel reset client as standalone fucntion

Hi, On Fri, Apr 22, 2022 at 04:29:42PM +0200, Arne Schwabe wrote: > This implement creating a reset packet without needing to setup a full control > session. I was about to merge this, with "it has a unit test, so what could go wrong". But... [ RUN ] test_generate_reset_packet_plain [

[Openvpn-devel] [PATCH applied] Re: Change reliable_get_buf_sequenced to reliable_get_entry_sequenced

Stared a bit at the code, for good measure. Does what it says. S-O-B added. Your patch has been applied to the master branch. commit 32f13c1e8902bd44c26b54de45f12e0cab642156 Author: Arne Schwabe Date: Fri Apr 22 16:29:45 2022 +0200 Change reliable_get_buf_sequenced to reliable_get_entry

[Openvpn-devel] [PATCH applied] Re: Move CRL reload to key_state_init from S_START transition

Thanks, Antonio, for the detailed testing. I already checked that "it's only code being moved" but since this is all magic event driven functions, I found "verifying functionality" important here. missing S-O-B added according to our developer docs. Your patch has been applied to the master bra

Re: [Openvpn-devel] [PATCH 16/28] Move CRL reload to key_state_init from S_START transition

On 27/04/2022 16:26, Gert Doering wrote: Hi, On Wed, Apr 27, 2022 at 04:04:41PM +0200, Antonio Quartulli wrote: On 22/04/2022 16:29, Arne Schwabe wrote: The current place that we reload is a bit more efficient since it only triggers reload after a completed 3way handshake. On the other hand

Re: [Openvpn-devel] [PATCH 16/28] Move CRL reload to key_state_init from S_START transition

Hi, On Wed, Apr 27, 2022 at 04:04:41PM +0200, Antonio Quartulli wrote: > On 22/04/2022 16:29, Arne Schwabe wrote: > > The current place that we reload is a bit more efficient since it only > > triggers reload after a completed 3way handshake. On the other hand the > > key_state_init is a much more

Re: [Openvpn-devel] [PATCH 16/28] Move CRL reload to key_state_init from S_START transition

Hi, On 22/04/2022 16:29, Arne Schwabe wrote: The current place that we reload is a bit more efficient since it only triggers reload after a completed 3way handshake. On the other hand the key_state_init is a much more logical place and with the upcoming HMAC based UDP code and TCP code, the init

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

And of course I forgot non-dco dummy implementation (which we don't call yet, because on Windows dco is always defined) https://github.com/lstipakov/openvpn/commit/f223bef8449f15ff5de06acdfee16088b855c47a ke 27. huhtik. 2022 klo 16.18 Lev Stipakov (lstipa...@gmail.com) kirjoitti: > How about we'

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

How about we'll add dco_check_timeout(int, context) to dco.h with platform specific implementations? Here is what I just did for Windows (Linux part is no-nop): https://github.com/lstipakov/openvpn/commit/ce242896c621273578a446c5194d5ca6aee04237 ke 27. huhtik. 2022 klo 15.32 Lev Stipakov (lstipa.

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

Hi, @Lev, just a heads up: does dco-win deal with this case? It would be > good to have a look on your side too. > Good point - this functionality (dco keepalive timeout) works in openvpn3 but not in openvpn2. dco-win notifies userspace about keepalive timeout by returning certain error code (ST

[Openvpn-devel] Summary of the community meeting (27th April 2022)

Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on libera.chat Date: Wed 27th April 2022 Time: 10:30 CEST (9:30 UTC) Planned meeting topics for this meeting were here: Your local meeting

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

On 27 Apr 2022, at 9:55, Antonio Quartulli wrote: > Hi Kristof, > > On 27/04/2022 09:48, Kristof Provost via Openvpn-devel wrote: >> From: Kristof Provost >> >> Handle the DCO driver telling us that the peer went away, even if we're >> not running in multi-instance mode. > > thanks for catching an

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

Hi, On 27/04/2022 09:59, Gert Doering wrote: Hi, On Wed, Apr 27, 2022 at 09:55:24AM +0200, Antonio Quartulli wrote: --- a/src/openvpn/forward.c +++ b/src/openvpn/forward.c @@ -,6 +,12 @@ process_incoming_dco(struct context *c) dco_do_read(dco); +if (dco->dco_message_

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

Hi, On Wed, Apr 27, 2022 at 09:55:24AM +0200, Antonio Quartulli wrote: > > --- a/src/openvpn/forward.c > > +++ b/src/openvpn/forward.c > > @@ -,6 +,12 @@ process_incoming_dco(struct context *c) > > > > dco_do_read(dco); > > > > +if (dco->dco_message_type == OVPN_NOTIF_DEL_P

Re: [Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

Hi Kristof, On 27/04/2022 09:48, Kristof Provost via Openvpn-devel wrote: From: Kristof Provost Handle the DCO driver telling us that the peer went away, even if we're not running in multi-instance mode. thanks for catching and fixing this. It was indeed on the todo list, but well hidden un

[Openvpn-devel] [PATCH] Handle (DCO) timeouts in client mode

From: Kristof Provost Handle the DCO driver telling us that the peer went away, even if we're not running in multi-instance mode. Signed-off-by: Kristof Provost --- src/openvpn/forward.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c in

[Openvpn-devel] [PATCHv2 DCO]: Handle (DCO) timeouts in client mode

Updated version of the timeout fix for client mode. This time with trigger_ping_timeout_signal() as suggested by Arne. Best regards, Kristof ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listin