On 15/03/23 04:57 PM, Bernhard Schmidt wrote: Hi,
> The upcoming DCO change will involve a new version of src:openvpn and a new > version > of src:openvpn-dco-dkms. The list of changes on the kernel side is already > visible > on https://github.com/OpenVPN/ovpn-dco/commits/master . > > In the past we managed to break DCO on above mentioned really heavily loaded > OpenVPN server within a few hours. The new version is a major overhaul and > more > in-line with code upstreamable in Linux, and did survive torture tests. > > I know this is kind of late, but I think it would be better to include it as > well > as soon as it is released because > > - we cannot support the old deprecated module > - openvpn uses DCO (of the right version) automatically and will transparently > fall-back to non-DCO mode if the module is not found (or the wrong version) > - it has not been in Bullseye previously, so if we see that DCO is too > unstable > with the new version we can just drop it before the release So, the release of 2.6.2 with the new DCO module has been done yesterday, fixing a number of bugs already present in 2.6.0. https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst --- New control packets flow for data channel offloading on Linux. 2.6.2+ changes the way OpenVPN control packets are handled on Linux when DCO is active, fixing the lockups observed with 2.6.0/2.6.1 under high client connect/disconnect activity. This is an INCOMPATIBLE change and therefore an ovpn-dco kernel module older than v0.2.20230323 (commit ID 726fdfe0fa21) will not work anymore and must be upgraded. The kernel module was renamed to "ovpn-dco-v2.ko" in order to highlight this change and ensure that users and userspace software could easily understand which version is loaded. Attempting to use the old ovpn-dco with 2.6.2+ will lead to disabling DCO at runtime. --- So I need some guidance from the release team how to proceed. I can think of - abandoning all of this, leading to a bookworm release using a buggy OpenVPN version with a DCO kernel interface that noone else uses - update experimental to 2.6.2 and the new DCO module, then ask for a approval for upload to unstable (2.6.1+2.6.2) in one go - upload 2.6.2 and the new DCO module to unstable right away - upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the new DCO in experimental for the second review round I would prefer the last option. Bernhard
