[Openvpn-devel] [PATCH applied] Re: Add unit test for reliable_get_num_output_sequenced_available
This adds the unit test for the previously introduced new function - and applies nicely on "v6 1/2". Tested on FreeBSD and Linux, and "it passes". .. [ RUN ] test_get_num_output_sequenced_available [ OK ] test_get_num_output_sequenced_available [==] 7 test(s) run. [ PASSED ] 7 test(s). PASS: packet_id_testdriver Since this got an ACK from Frank, I did not spend much stare-at-code to verify that it actually tests something useful - I *have* found a tab error in tests/unit_tests/openvpn/Makefile.am, though, and fixed on the fly :-) Your patch has been applied to the master branch. commit a5a30ec311ce9d0dbcd6162daab97a225189d570 Author: Arne Schwabe Date: Wed Sep 21 12:49:30 2022 +0200 Add unit test for reliable_get_num_output_sequenced_available Signed-off-by: Arne Schwabe Acked-by: Frank Lichtenheld Message-Id: <20220921104930.3452270-3-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25292.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: Refactor/optimise code sending TLS control channel messages
Acked-by: Gert Doering
This is a slightly complicated ACK - this is a respin of 1/3 v4 with
the "Ensure that control channel packet are respecting maximum packet size"
patch, which has an ACK from Frank Lichtenheld. During testing of v4
I noticed that it it brings a regression for "very small packets"
(--link-mtu 440 and below) - not that these are overly useful, but if
it worked before, why shouldn't it stop afterwards? So I started a
discussion on IRC which ended here.
Most of this patch is identical to "1/3 v4", except for a typo fix :-),
avoiding an integer underrun ("tmp.len > 0" now), removing the 2 byte
TCP length from "overhead", using the actual AF_ instead of always
going for AF_INET, and most important, the "maxlen < TLS_CHANNEL_BUF_SIZE"
that broke "very small packets" in v4 got changed to "for really really
small packets, we might exceed the MTU", but this is in the order of
"16 bytes payload". Better die trying than not try at all...
The "if (maxlen < 16)" bit looks a bit strange, setting maxlen to 16
(okay) and max_pkt_len to TLS_CHANNEL_BUF_SIZE - if we get there with
maxlen = 16, max_pkt_len will also be something like "16" (assuming
rel_avail == 1 and no WKC) or maybe "32", but nowhere near 1250...
OTOH it is of no real significance, as "maxlen" controls how many
bytes we'll ever request as payload - so, 16+WKC, well below 1250.
I am a bit concerned that the inner loop in write_outgoing_tls_ciphertext()
could end up as an endless loop, if "max_pkt_len" ends up being <=
"buf_len(session->tls_wrap.tls_crypt_v2_wkc))", so the max_int()
ends up with "len == 0", buf_copy_n() copying nothing, and the loop
repeating "send packets with a WKC and nothing else", forever.
OTOH, this needs a very small MTU to start with, which is not possible
to trigger with this patch alone (--link-mtu below 125 is refused
with "TUN MTU value (nn) must be at least 100" error). But I'd still
like either confirmation that I have overlooked something, or maybe
adjust the max_int() to "1, ..." so it's clear we'll always handle
1 byte per loop, whatever happens...
Another observation: getting rid of all the "if (maxlenmtu_mtu" and "TLS_CHANNEL_BUF_SIZE" while the
code does "1250" magic numbers - but these get fixed in 2/2.
This all said, I did my best to break master + this patch, and couldn't
find a way - so, merged. I tested server side (without any special
MTU settings) and client side with --link-mtu $various, comparing the
UDP output I saw in tcpdump. We're still exceeding the --link-mtu
value for some cases (--link-mtu 125 -> UDP payload 121 bytes for a
few packets, and "72" for very many of them, both not really "125"
- and I wonder where the 72 is coming from, leaving lots of space
unused. With --link-mtu 200, the maximum I saw is 171 bytes, so
at least this patch tends to underflow available MTU (and same thing
for 300/271, 400/371). Will come back to this with 2/2 v6 :-)
Your patch has been applied to the master branch.
commit 4e9e25a9e547ab6e1f71003947a2d186dc231cb6
Author: Arne Schwabe
Date: Fri Nov 4 13:56:54 2022 +0100
Refactor/optimise code sending TLS control channel messages
Signed-off-by: Arne Schwabe
Acked-by: Gert Doering
Message-Id: <20221104125655.656150-1-a...@rfc2549.org>
URL:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25478.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] win32: detect arm64 architecture and emulations
I have tested following configurations:On my Volterra:- x86 on arm64 win11- x64 on arm64 win11- arm64 on arm64 win11On my laptop:- x86 on amd64 win10 - amd64 on amd64 win10On VM:- x86 on amd64 win7- amd64 on amd64 win7If you want to test, you could get binaries (enough to run openvpn —version) from my GHA fork (https://github.com/lstipakov/openvpn/actions/runs/3392266010). I can also open a PR to openvpn-build and modify GHA script so that it points to my openvpn branch, this way we could get MSIs. Lähetetty iPhonestaGert Doering kirjoitti 5.11.2022 kello 11.40:Hi,On Fri, Nov 04, 2022 at 11:02:47AM +0200, Lev Stipakov wrote:From: Lev Stipakov Properly detect process architecture andmachine architecture, including arm64.Print process architecture and, if machinearchitecture is different (we are running inemulation), print that too.This looks generally good, so definitely a "feature ACK".Do you have a set of installers available so we can ask for testers? I can do win10+win11 on arm64, but would perfer if someone else woulddo i386/amd64 win7/10/11/server* testing.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 MistressGert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: Binary data ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] win32: detect arm64 architecture and emulations
Hi, On Fri, Nov 04, 2022 at 11:02:47AM +0200, Lev Stipakov wrote: > From: Lev Stipakov > > Properly detect process architecture and > machine architecture, including arm64. > > Print process architecture and, if machine > architecture is different (we are running in > emulation), print that too. This looks generally good, so definitely a "feature ACK". Do you have a set of installers available so we can ask for testers? I can do win10+win11 on arm64, but would perfer if someone else would do i386/amd64 win7/10/11/server* testing. 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
