# \[Testing\] IPFire 2.29 – Core Update 197 **URL:** \ **Category:** Community\ **Created:** [11 August 2025 10:53 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510 "2025-08-11T10:53:16Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ag](https://community.ipfire.org/user_avatar/community.ipfire.org/ag/32/12124_2.png) [@ag](https://community.ipfire.org/u/ag)\ **Post date:** [11 August 2025 10:53 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/1 "2025-08-11T10:53:16Z")
Hi all, We’ve opened up **IPFire 2.29 – Core Update 197** for testing. Blog post with full details: [https://www.ipfire.org/blog/ipfire-2-29-core-update-197-is-available-for-testing](https://www.ipfire.org/blog/ipfire-2-29-core-update-197-is-available-for-testing) ### Highlights - **OpenVPN 2.6 upgrade** – modernised codebase with better security and wider client compatibility. Existing configs should keep working. - **Power saving / CPU frequency** – systems now clock down by default using Intel P-State or the kernel’s `schedutil` governor (where supported), reducing power and heat. `cpufrequtils` is no longer needed. - Plus the usual stack of security and package updates, kernel rebase, and a few nice quality-of-life fixes (see blog). * * * ## What we need you to test ### 1) OpenVPN - Connectivity with **older and newer clients** (Windows, macOS, Linux, mobile). - Importing the **single-file client config** into your clients. - Behaviour of **cipher negotiation** (and any fallback). - Any warnings related to **compression** on legacy clients. - Road-warrior **restart behaviour** (clients should reconnect cleanly). Please include client OS/version, OpenVPN client version, and any relevant logs if you hit issues. ### 2) CPU frequency / power - Whether your system uses **Intel P-State** or **schedutil** after the update. - Impact on **idle power draw** , **temperatures** , and **latency/throughput** under load. - Any regressions versus your previous governor settings. Hardware details (CPU model, platform, NICs) and before/after observations are super helpful. ### 3) General checks - Upgrade path from your current Core Update. - Restoring **\>2 GiB backups** via the web UI. - WireGuard: importing configs with **Windows line endings**. - Anything else you rely on day-to-day (add-ons, reporting, IPS, etc.). * * * ## How to get it [Switch to the Testing channel](https://www.ipfire.org/docs/configuration/ipfire/pakfire/testing) and update to **Core Update 197**. As always, [take a backup](https://www.ipfire.org/docs/configuration/system/backup) before you start. Please post results and issues in this thread so we can keep feedback in one place. Constructive, reproducible reports with logs make fixes much faster for everyone. Thanks for helping us shake this one down! Cheers, A G ---
**Author:** ![ms](https://community.ipfire.org/user_avatar/community.ipfire.org/ms/32/16615_2.png) [@ms](https://community.ipfire.org/u/ms)\ **Post date:** [11 August 2025 11:09 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/2 "2025-08-11T11:09:58Z")
Hello everyone, > [@ag](#): > > Please include client OS/version, OpenVPN client version, and any relevant logs if you hit issues. This is very _very_ important! We have made so many changes to OpenVPN and we have tested it very well, too. However, with so many different deployments out there, we would really appreciate if all of you could help us to verify that there are no regressions here. There should not be, instead you are getting a lot of new features and protection! ---
**Author:** ![mangrove](https://community.ipfire.org/user_avatar/community.ipfire.org/mangrove/32/16629_2.png) [@mangrove](https://community.ipfire.org/u/mangrove)\ **Post date:** [11 August 2025 12:04 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/3 "2025-08-11T12:04:11Z")
Looks good so far, I have only tested Net2Net connections on this Testing however – connecting a 197 client to multiple 196 and 194 systems. But everything seems to work and the OpenVPN UI is much nicer now, too. Running 197 virtualized under KVM btw. ---
**Author:** ![tphz](https://community.ipfire.org/user_avatar/community.ipfire.org/tphz/32/16551_2.png) [@tphz](https://community.ipfire.org/u/tphz)\ **Post date:** [11 August 2025 17:30 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/7 "2025-08-11T17:30:23Z")
> [@ag](#): > > 1. OpenVPN IPFire 2.29 (x86\_64) - Core-Update 197 Development Build: master/87e1047a ![obraz](https://community.ipfire.org/uploads/default/original/2X/1/15d0dfe52b7706f032471335bbaa081af2f30257.png) After the upgrade, the selection disappeared. When you select and click `Save Advanced Settings` - the setting does not save. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 August 2025 17:48 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/8 "2025-08-11T17:48:41Z")
It does actually save it into the `/var/ipfire/ovpn/settings` file, it just doesn’t save the settings on the advanced page, which it should do. It also doesn’t update the TLS-Authentification-Key which stays at what looks to be a SHA2-512 and is what is embedded in the .ovpn file. The SHA2-512 was changed to be the default value but it should get changed on the TLS-Authentification-Key entry to the one that was selected. If you leave the TLS enabled checkbox unchecked and save then the settings file has it as disabled and the .ovpn file ends up without any TLS cert entry as it should do so that works. It is just if it is enabled then SHA2-512 is always selected irrespective of hash has been selected. Can you please raise a bug for this issue. [https://www.ipfire.org/docs/devel/bugzilla](https://www.ipfire.org/docs/devel/bugzilla) ---
**Author:** ![tphz](https://community.ipfire.org/user_avatar/community.ipfire.org/tphz/32/16551_2.png) [@tphz](https://community.ipfire.org/u/tphz)\ **Post date:** [11 August 2025 18:02 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/9 "2025-08-11T18:02:43Z")
> [@bonnietwin](#): > > Can you please raise a bug for this issue. > [www.ipfire.org - Bugzilla](https://www.ipfire.org/docs/devel/bugzilla) > **[13869 – OpenVPN - \[Testing\] IPFire 2.29 – Core Update 197 - TLS Channel...](https://bugzilla.ipfire.org/show_bug.cgi?id=13869)** ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 August 2025 18:14 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/10 "2025-08-11T18:14:37Z")
Interestingly, the issue with the TLS hash not being used as selected was already present in CU196. In that version changing the value was saved but the TLS-Authentification-Key was always the same also. Never changed. Not sure how long that has been like that. Would just mean that whatever hash you selected it would always make the TLS key the same value (SHA2-512 I believe). However if the cipher selected is AES-GCM then that has an inbuilt hash anyway so any hash selected will be ignored anyway by the client. However, if you used an AES-CBC cipher then the .ovpn file would have the selected TLS hash defined but if that was not SHA2-512 then the ta.key and the TLS hash type would not match in the client. This has been like this since at least CU196 but probably much longer. I will test out what happens if the above situation occurs with CU196. EDIT: I have confirmed that the ta.key is always a 2048 bit key irrespective of which TLS hash is selected in CU196 and also back in CU189. I will additionally provide my input into the bug report. EDIT: I have realised that I have been mixing things up. The ta.key is used to create the hmac using the appropriate hash that is define in the DAUTH setting. So the ta.key is created once and never changes. Then the tls-auth entry being enabled causes the client to create the hmac using the selected hash and the ta.key at the server allows it to decrypt that and confirm the hmac. So the only issue is that the settings are saved into the settings file but not shown in the advanced settings wui page. Simpler issue. Sorry for the noise from myself. ---
**Author:** ![xperimental](https://community.ipfire.org/user_avatar/community.ipfire.org/xperimental/32/16702_2.png) [@xperimental](https://community.ipfire.org/u/xperimental)\ **Post date:** [11 August 2025 18:38 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/11 "2025-08-11T18:38:39Z")
Isn’t there a installation media to test the whole thing? ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 August 2025 18:44 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/12 "2025-08-11T18:44:34Z")
Could you explain what you mean. There is the installation iso for CU197 Testing that can be used for a fresh install instead of an upgrade but I am not sure if that is what you are meaning. ---
**Author:** ![xperimental](https://community.ipfire.org/user_avatar/community.ipfire.org/xperimental/32/16702_2.png) [@xperimental](https://community.ipfire.org/u/xperimental)\ **Post date:** [11 August 2025 18:57 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/13 "2025-08-11T18:57:46Z")
Yes, but where. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 August 2025 19:00 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/14 "2025-08-11T19:00:37Z")
x86\_64 [https://nightly.ipfire.org/master/latest/x86\_64/](https://nightly.ipfire.org/master/latest/x86_64/) aarch64 [https://nightly.ipfire.org/master/latest/aarch64/](https://nightly.ipfire.org/master/latest/aarch64/) ---
**Author:** ![xperimental](https://community.ipfire.org/user_avatar/community.ipfire.org/xperimental/32/16702_2.png) [@xperimental](https://community.ipfire.org/u/xperimental)\ **Post date:** [11 August 2025 19:21 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/15 "2025-08-11T19:21:46Z")
Thanks. Can you please put that links in your further announcements? ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 August 2025 19:29 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/16 "2025-08-11T19:29:54Z")
Those links will always be the same as when the Testing version is released it is in the master branch. So you can just create bookmarks for those url’s. ---
**Author:** ![xperimental](https://community.ipfire.org/user_avatar/community.ipfire.org/xperimental/32/16702_2.png) [@xperimental](https://community.ipfire.org/u/xperimental)\ **Post date:** [11 August 2025 19:32 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/17 "2025-08-11T19:32:11Z")
And you can put those in your announcements 😉 . ---
**Author:** ![pscar13](https://community.ipfire.org/user_avatar/community.ipfire.org/pscar13/32/16558_2.png) [@pscar13](https://community.ipfire.org/u/pscar13)\ **Post date:** [11 August 2025 20:02 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/18 "2025-08-11T20:02:18Z")
openVPN no longer works after upgrade 197 on my IPFire test (It works on 196) Here’s my configuration 196 ![Capture d'écran 2025-08-11 214126](https://community.ipfire.org/uploads/default/original/2X/6/6b05ed70bee4453918ec28b032242e149003669c.png) I get this message upon reboot ![ipfire-2025-08-11-21-45-27](https://community.ipfire.org/uploads/default/original/2X/9/9a96438e6f4442af369c36e69816a52a57e6626a.png) Here’s the connection log from my Android phone (OpenVPN for Android 0.7.61) `2025-08-11 21:52:37 AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)` `2025-08-11 21:52:37 TCP/UDP: Closing socket` `2025-08-11 21:52:37 SIGTERM[soft,auth-failure] received, process exiting` `2025-08-11 21:52:37 MANAGEMENT: >STATE:1754941957,EXITING,auth-failure,` `2025-08-11 21:52:37 Unscheduling VPN keep alive` ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 August 2025 21:43 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/20 "2025-08-11T21:43:10Z")
> [@pscar13](#): > > I get this message upon reboot Do you get this every time you reboot? It looks like during stopping the openvpn road warrior server is successfully stops the openvpn-rw daemon but then the next part of the initscript is flushing all the firewall rules and the xtables.lock is still in place from some previous step but I can’t figure out from what. Do you have a lot of firewall rules in your setup. By a lot I mean like 100 or more? In all my tests of updating from CU196 to CU197, first when it was still in unstable, with many many updates and then with the Testing release where I have run 7 system updates, I have never seen that message about the xtables.lock file. I am not sure what other application could be holding the xtables lock. Can you confirm that you have squid, the web proxy, disabled. If enabled then the first app that is shutdown is squid, followed by grub-btrfsd, then fcron then the openvpn-rw which shuts down the openvpn authenticator followed by the openvpn road warrior server. So no squid being shown should indicate squid is disabled. grub-btrfsd is not running so it can’t be holding the xtables lock and the fcron initscript doesn’t call anything to do with the firewall. If you are able to reproduce this every reboot then I would raise a bug on it. Then someone more knowledgeable can help you track down what the issue is. > [@pscar13](#): > > 2025-08-11 21:52:37 AUTH: Received control message: AUTH\_FAILED,Data channel cipher negotiation failed (no shared cipher) This means that none of the default set of AES-GCM 256 bit, AES-GCM 128 bit and ChaCha20-Poly1305 ciphers matched with any ciphers that your client was able to negotiate. I am also using the same version of OpenVPN for Android and mine connected with no problems. My original cipher I had defined was AES-GCM 256 bit. It looks like you had selected AES-CBC 256 bit. Go into the advanced settings section and try adding the AES-CBC 256 bit entry in the ciphers section. You can also try adding the AES-CBC 256 bit entry in the Fallback Cipher entry. Alternatively you could change the cipher on the client from AES-CBC 256 bit to AES-GCM 256 bit. I will try and find some time over the next few days/week to set up a CU196 system with AES-CBC 256 bit on the server and the android client and the see what happens with an update to CU197. ---
**Author:** ![pscar13](https://community.ipfire.org/user_avatar/community.ipfire.org/pscar13/32/16558_2.png) [@pscar13](https://community.ipfire.org/u/pscar13)\ **Post date:** [12 August 2025 00:21 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/21 "2025-08-12T00:21:30Z")
This is just a migration test. > [@bonnietwin](#): > > Do you get this every time you reboot? No, I only get this message upon first shutdown after the update I no longer get it after that. My firewall only has about fifty rules. Squid is enabled. For OpenVPN, AES-CBC (256 bit) was the default value on IPFire when I created it. I don’t have a phone to test another configuration at the moment. If I need to change my OpenVPN configuration in 197, I’ll switch to Wireguard instead. Thank you for your investigation. ---
**Author:** ![xperimental](https://community.ipfire.org/user_avatar/community.ipfire.org/xperimental/32/16702_2.png) [@xperimental](https://community.ipfire.org/u/xperimental)\ **Post date:** [12 August 2025 03:09 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/22 "2025-08-12T03:09:01Z")
So this is finally gone after the first reboot? ---
**Author:** ![pscar13](https://community.ipfire.org/user_avatar/community.ipfire.org/pscar13/32/16558_2.png) [@pscar13](https://community.ipfire.org/u/pscar13)\ **Post date:** [12 August 2025 03:50 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/23 "2025-08-12T03:50:07Z")
Yes, the message only occurred during the first shutdown after the upgrade, without any further incident. ---
**Author:** ![xperimental](https://community.ipfire.org/user_avatar/community.ipfire.org/xperimental/32/16702_2.png) [@xperimental](https://community.ipfire.org/u/xperimental)\ **Post date:** [12 August 2025 06:01 UTC](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/24 "2025-08-12T06:01:20Z")
KVM, UEFI, RAID: still not working ![{C6769C48-5657-4E67-8751-00DB8458C5BB}](https://community.ipfire.org/uploads/default/original/2X/a/ab6734017baaee2097888ff39d76452008b7d136.png) [Next page](https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510.md?page=2)