From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4dbCRT19Hjz332V for ; Tue, 23 Dec 2025 11:27:49 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dbCRP4Md5z2xQT for ; Tue, 23 Dec 2025 11:27:45 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4dbCRN28tRzF8; Tue, 23 Dec 2025 11:27:44 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1766489264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bTeLFdhIbKplGH+uESb5e5wEg/DqBpB0diyoL9aWKg0=; b=CSC9KHoETXivQA6ELtAOYtzToXXYYxwbglBCY52A7BmdE8M1OD7zyTdEp/W4QLtTOj3HMO drpqXuTneVwWNNCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1766489264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bTeLFdhIbKplGH+uESb5e5wEg/DqBpB0diyoL9aWKg0=; b=dzTbCv+oVVGonJj1QA2AvjAcGZtaFPd29htpy1CKDGrGhYYxCLtenUGzhBoPq1iCHZKvqM kn5BEq+wO43xj9hOCPC9snLRbYUdkOzdWOlQGxV7ICqX3wwFg20TPxskL4bnQNhlSlBbIW FeikFwVZFf7o7qIM6zk2S5D1CxJIgPj6HUirZRLLW0F+BY0o7CDKvxqLoaBeqfqdaRPUev brcmUwv44TP2b3HBJWP0dM7AS0aIIsx9SKQJ5DN+ZYk+o32et9I9dj67acJDHP49DW+5AP LSsLs05FM3mjKlDnXQoj/R56NvUWUGOsqLiBysXjpM/INMJIQ95KRqKbhyhupg== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: openvpn-2.7_rc1 From: Michael Tremer In-Reply-To: <95de13b9655902ecd319bb998a94bdd8f10186b7.camel@ipfire.org> Date: Tue, 23 Dec 2025 12:27:43 +0100 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4247a605-6aac-4c9c-93c8-db236c2cb769@ipfire.org> <95de13b9655902ecd319bb998a94bdd8f10186b7.camel@ipfire.org> To: ummeegge Hello Erik, Great that you are already testing OpenVPN 2.7. As we have already seen = a couple of RCs, the release should be fairly close. We will probably = upgrade very quickly after the final version has been released. However, I believe that OpenVPN 2.6 should already be supporting DCO, = however there is this message in the logs: configure: WARNING: DCO cannot be enabled when using iproute2 configure: WARNING: DCO support disabled So you are right with your changes to the configure command. Since we = won=E2=80=99t have to wait until 2.7 is release, would you be able to = submit a patch so we can ship a DCO-enabled OpenVPN with the new kernel? > On 20 Dec 2025, at 19:05, ummeegge wrote: >=20 > Hello Adolf and all, > wanted to deliver also some results to the 2.7 version of OpenVPN, > which is currently on rc4 release. Meanwhile i use the rc4 candidate > with the new Kernel 6.18.1 which Arne delivered for testing. >=20 > Have compiled rc4 with the following diff > ` > @@ -73,10 +73,10 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > cd $(DIR_APP) && ./configure \ > --prefix=3D/usr \ > --sysconfdir=3D/var/ipfire/ovpn \ > - --enable-iproute2 \ > --enable-plugins \ > --enable-plugin-auth-pam \ > - --enable-plugin-down-root > + --enable-plugin-down-root \ > + --enable-dco >=20 > ` and it uses the new ovpn Kernel modul out of the box if no CBC = Cipher > is in usage. Have set in the WUI `--data-cipher-fallback` to disabled > and configured only GCM and ChaCha20 as Ciphers (if there is CBC > somewhere included, DCO will disable itself at startup). > So there was no more configuration needed to enable the "Data Channel > Offload" . These are some serious limitations, but in the current default = configuration our users should not walk into this. Should we add a note to the CBC ciphers in the selection box that = choosing them would disable DCO? > Made some rudimentary speedtests with speedtest.net with an Fedora 43 > client via WLAN with this scenarios: > 1) Direct and without OpenVPN to get a reference value of the line=20 > 2) non-DCO OpenVPN 2.6 on client and server (without DCO) > 3) Server-DCO OpenVPN-2.7_rc4 on IPFire (as Server) and with 2.6 > (without DCO) on client side and > 4) Full-DCO on both ends OpenVPN-2.7_rc4 with enabled DCO >=20 > which i wanted to provide here for you. >=20 > Download: > Direkt: 49.39 Mbps > non-DCO: 23.99 Mbps This is an insane drop. Why would it drop so much when the bottleneck is = clearly the WiFi and not OpenVPN? > Server-DCO: 44.63 Mbps > Full DCO: 47.84 Mbps >=20 > Upload: > Direkt: 20.93 Mbps > non-DCO: 19.66 Mbps > Server-DCO: 20.59 Mbps > Full DCO: 20.54 Mbps >=20 > Idle latency: > Direkt: 14 ms > non-DCO: 15 ms > Server-DCO: 16 ms > Full DCO: 15 ms >=20 > Download latency: > Direkt: 41 ms > non-DCO: 171 ms The same goes here. This is a huge increase in latency which will = explain the large drop in throughput. > Server-DCO: 53 ms > Full DCO: 58 ms >=20 > Upload latency: > Direkt: 35 ms > non-DCO: 37 ms > Server-DCO: 36 ms > Full DCO: 35 ms >=20 > Was at first not sure if something went wrong and i e.g. bypassed > accidentially the tunnel but mtr showed that all is OK. >=20 > I know that these results are not representative but i wanted > nevertheless to let you know. May someone wants to give it also a try. >=20 > Also, a lot hass been changed to the better in 2.7 IMHO. Like what? I think the major changes have been happening in 2.6 and 2.7 = only requires minimal changes in the IPFire tooling to make the upgrade = work. All the best, -Michael >=20 > Best, >=20 > Erik >=20