I've stared at the code (nice, things get simpler :-) ) and done a few tests (v4 over v4, v4 over v6, ...) with "--mssfix 1000" and looked at the resulting MSS values. These are way different from "master without this" - but arguably, closer to reality than what we had before.
Old: BF-CBC, --mssfix 1000 -> MSS 804 / 784 AES256GCM, --mssfix 1000 -> MSS 856 / 876 New: BF-CBC, --mssfix 1000 -> MSS 892 / 872 AES256GCM, --mssfix 1000 -> MSS 904 / 884 I have not done more sophisticated counting on whether the new values are *correct*, but tcpdump claims they are: - "AES256GCM, mssfix 1000", "ssh -4 $remote ls -lR" 16:55:40.171255 IP 194.97.140.11.51194 > 193.149.48.178.50377: UDP, length 1000 16:55:40.171267 IP 194.97.140.11.51194 > 193.149.48.178.50377: UDP, length 1000 16:55:40.171270 IP 194.97.140.11.51194 > 193.149.48.178.50377: UDP, length 1000 - "AES256GCM, mssfix 1000", "ssh -6 $remote ls -lR" 16:57:04.871238 IP 194.97.140.11.51194 > 193.149.48.178.50377: UDP, length 1000 - IPv6 transport is a also correct (which surprises me a bit, I have not seen a reference to the underlying protocol, which changes the "headroom" we have). At least, sometimes... with AES256GCM: 16:58:31.681280 IP6 2001:608:0:814::f000:11.51194 > 2001:608:4::ce:c0f.65297: UDP, length 1000 16:58:31.681289 IP6 2001:608:0:814::f000:11.51194 > 2001:608:4::ce:c0f.65297: UDP, length 1000 - over IPv6 transport, with BF, max packets are off by 8 bytes 17:13:54.561605 IP6 2001:608:0:814::f000:11.51194 > 2001:608:4::ce:c0f.28958: UDP, length 1008 17:13:54.561760 IP6 2001:608:0:814::f000:11.51194 > 2001:608:4::ce:c0f.28958: UDP, length 1008 (which is closer to what I'd expect, but still weird, why not 1020? ... my machines do weird stuff here...) That said, the code has been subjected to t_client tests as well, which were uneventful (there is nothing that excercises TCP in there), as expected. The new frame_calculate_mssfix() looks a bit confused regarding "do we declare + initialize variables in one or two steps", and "do we call it 'unsigned' or 'unsigned int'". But this can be fixed in a followup cleanup patch ;-) Not sure I understand what the old code does here, looking at "tun_mtu_dynamic" - this looks like "adjust to discovered MTU", but the documentation of --mssfix does not speak about this ... so it will be interesting to revisit this (documentation + option) eventually and see if/how we want to consider MTU discovery. Your patch has been applied to the master branch. commit d4458eed0c3cf582f787893f033a19cb4629cd76 Author: Arne Schwabe Date: Tue Dec 14 16:09:01 2021 +0100 Decouple MSS fix calculation from frame calculation Signed-off-by: Arne Schwabe <a...@rfc2549.org> Acked-by: Frank Lichtenheld <fr...@lichtenheld.com> Message-Id: <20211214150901.4118886-1-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23423.html Signed-off-by: Gert Doering <g...@greenie.muc.de> -- kind regards, Gert Doering _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel