Hello,
Follow-up to correct and add context to my earlier report.
First, a correction: I had adapted upstream commit 7791f535 ("dco: process
messages immediately after read", fixes #919) by hand, not realising the fix
had already been backported to the upstream release/2.6 branch and
shipped in
the OpenVPN 2.6.20 stable release. This was confirmed by Gert Doering on
openvpn-devel:
https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/aj2LVcoBm4HVKF8M%40greenie.muc.de/#msg59351313
7791f535:
https://github.com/OpenVPN/openvpn/commit/7791f5358a5574d4ef1bd27e2d52300c9d98bd72
The upstream backport is not a single commit but a reviewed 3-commit series
(authored on top of v2.6.19, Acked-by Gert Doering):
1fbbe91d dco linux: avoid redefining ovpn enums (2.6)
https://github.com/OpenVPN/openvpn/commit/1fbbe91d292fb925f5af73b512d7d1c83abfe714
876a8cf5 dco: port core/context infrastructure needed for backport
of 7791f53
https://github.com/OpenVPN/openvpn/commit/876a8cf5fd6166a22bfe6b6f37889d3cff3a17c6
e78a8af2 dco: backport immediate notification processing on Linux and
FreeBSD (Github: fixes OpenVPN/openvpn#919)
https://github.com/OpenVPN/openvpn/commit/e78a8af2f5ce5ef3bbfefc2dc8efeca84027c018
This series does NOT cleanly cherry-pick onto the trixie base (2.6.14):
876a8cf5/e78a8af2 conflict because they sit on top of the DCO peer-float
backport and the DCO/persist-tun reconnect repair that landed in
2.6.15-2.6.19:
b0b123b3 dco: backport OS-independent part of peer float support
https://github.com/OpenVPN/openvpn/commit/b0b123b3a7d6b64e236bc0b9836cb73d76c130e2
3c9fe881 dco: support float notifications on FreeBSD
https://github.com/OpenVPN/openvpn/commit/3c9fe881207df94e938ba7325a0cd46765d6ba6c
fae4a9e3 Repair interaction between DCO and persist-tun after
reconnection
https://github.com/OpenVPN/openvpn/commit/fae4a9e3f51554bdecc9df45344135006da1f0d9
So I see two honest options, each with a real downside, and I'm genuinely
unsure which fits stable policy best:
1) The targeted patch I originally attached. It is significantly
smaller and
lower-risk than the full upstream delta, so as a minimal stable fix it
isn't unreasonable. The downside is that it diverges from upstream:
it is
a reimplementation rather than what upstream shipped, and it would make
pulling in any future DCO fixes harder, since later cherry-picks would
conflict against a non-upstream base. I'm not really comfortable
with that.
2) Take the upstream fix as released, i.e. effectively the whole
2.6.15-2.6.19 DCO delta (the 2.6.20 release). This is
upstream-aligned and
keeps future maintenance clean, but it is a much larger change than a
typical stable update and would be the SRM's call.
I'll defer to the maintainer and the SRM on which (if either) is appropriate
for trixie. I'm happy to help test or review whichever direction you prefer,
including re-rolling the targeted patch with proper DEP-3 provenance if
that's
the path, or validating a 2.6.20-based build.
For what it's worth, the fix is already available to trixie users today via
trixie-backports (openvpn 2.7.x carries it natively), so there is a
supported
path for anyone hitting this on stable in the meantime.
Cheers,
Thomas
