[Openvpn-devel] Community meetings in February 2022

2022-02-02 Thread Samuli Seppänen
Hi, Next community meetings have been scheduled to - Wed 2nd February 2022 at 10:30 CET (ongoing) - Wed 9th February 2022 at 10:30 CET - Wed 16th February 2022 at 10:30 CET - Wed 23rd February 2022 at 10:30 CET The place is #openvpn-meeting IRC channel at libera.chat Meeting agendas and sum

[Openvpn-devel] Summary of the community meeting (2nd February 2022)

2022-02-02 Thread Samuli Seppänen
Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on libera.chat Date: Wed 2nd February 2022 Time: 10:30 CET (9:30 UTC) Planned meeting topics for this meeting were here: Your local meetin

[Openvpn-devel] [PATCH applied] Re: Fix mssfix and frame calculation in CBC mode

2022-02-02 Thread Gert Doering
Acked-by: Gert Doering This came out of discussions on the "last" mssfix patch (d4458eed0c3, "Decouple MSS fix calculation") where I discovered that sometimes we'd still see too-big payloads for BF-CBC - this was a rounding issue, and also an interpretation issue on "which parts of the frame ar

Re: [Openvpn-devel] [PATCH v5] Change buffer allocation calculation and checks to be more static

2022-02-02 Thread Gert Doering
Hi, On Mon, Jan 24, 2022 at 03:54:59AM +0100, Arne Schwabe wrote: > Currently we use half dynamic buffer sizes where we use have a fixed > overhead for crypto (crypto_max_overhead) but use a dynamic overhead > for the the other small header sizes. > > Patch v3: rebase > Patch v4: add size of ack

[Openvpn-devel] [PATCH applied] Re: Change buffer allocation calculation and checks to be more static

2022-02-02 Thread Gert Doering
Acked-by: Gert Doering Tested on client and server side, all "regular" stuff works, but it breaks my TCP/P2P/P2P-NCP test case for big packets, namely... 2022-02-02 12:57:19 TCP/UDP packet too large on write to [AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499) (expected result: ove

[Openvpn-devel] [PATCH applied] Re: Change buffer allocation calculation and checks to be more static

2022-02-02 Thread Gert Doering
Acked-by: Gert Doering Tested on client and server side, all "regular" stuff works, but it breaks my TCP/P2P/P2P-NCP test case for big packets, namely... 2022-02-02 12:57:19 TCP/UDP packet too large on write to [AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499) (expected result: ove

[Openvpn-devel] [PATCH applied] Re: Fix datagram_overhead and assorted functions

2022-02-02 Thread Gert Doering
Acked-by: Gert Doering For reference, this was 12/21 in the first patch series, and got an ACK from Frank Lichtenheld there. Stared at the code. Looks bigger than it really is :-) - what it really does is pass on the socket address family down the call chain to the "datagram_overhead()" functio

Re: [Openvpn-devel] [PATCH v2 2/2] msvc: switch to openssl3

2022-02-02 Thread Antonio Quartulli
Hi, On 26/01/2022 13:35, Lev Stipakov wrote: From: Lev Stipakov Add openssl3 vcpkg port, which is slightly modified version of openssl1.1.1 port from official vcpkg repo. Signed-off-by: Lev Stipakov Built this branch using GH actions and it worked for all archs. I also smoke tested the x64

Re: [Openvpn-devel] [PATCH 1/2] crypto: move validation logic from cipher_get to cipher_valid

2022-02-02 Thread David Sommerseth
On 26/01/2022 17:28, Antonio Quartulli wrote: With cipher validation performed in cipher_get(), a cipher is never returned in any case if some check fails. This prevents OpenVPN from operating on all ciphers provided by the SSL library, like printing them to the user. Move the validation logic

[Openvpn-devel] [PATCH applied] Re: msvc: switch to openssl3

2022-02-02 Thread Gert Doering
Haven't tested anything. If you and Antonio say this works, good enough :) Your patch has been applied to the master branch. commit 225893ef7d06cdaf145436c54bd1070266a1d1da Author: Lev Stipakov Date: Wed Jan 26 14:35:02 2022 +0200 msvc: switch to openssl3 Signed-off-by: Lev Stipako

[Openvpn-devel] [PATCH applied] Re: Implement optional mtu parameter for mssfix

2022-02-02 Thread Gert Doering
Acked-by: Gert Doering Change makes sense, to take IPv4/IPv6 encap into account. Code looks reasonable. Tested with my previous mssfix test setup (and looking very carefully at tcpdump-reported "length" values, which one is "packet" and which one is "UDP encap" length :-) - that got me confus