I thank you @jon
In fact, I did so.
I meant if you could download the test version while avoiding the upgrade.
In the sense that since I did the clean installation for testing, installing CU174 right away was more practical (in my case).
But from the link you sent me, I am convinced it is the only way 
.
Pardon my English. I use “deepl” but I have strong suspicions that automatic translators are never the best.
Hi @casabenedetti,
the first two warnings are deprecation warnings according to the update to the new OpenVPN-2.6.x version. A more detailed description are located in here → OpenVPN 2.6 Development version - #3 by ummeegge .
The third error message is old and known and is also correct in terms of the OpenVPN handling according to his configuration. Since OpenVPN drops his privileges to an unprivleged user (nobody) while starting the instance, the process is after a SIGTERM (stopping the process) not capable to execute the deletion of the routes (kernel space), therefor you would need plugins like down-root but the system makes this on itself after a period of time.
Hope this helps. Best,
Erik
Thank you very much @ummeegge
I was convinced that I had misconfigured something.
Hi @casabenedetti , you can download an iso or img of the Testing version.
The wiki has a link to the nightly builds
https://wiki.ipfire.org/devel/nightly-builds
which gives details about the builds that are automatically done for both the Testing and Unstable trees.
Follow the nightly build link
and select “master” then “latest” then the architecture you are interested in (x86_64 or aarch64) and you will have a directory with the latest versions of the Testing branch with both iso and img files together with their b2sum files so you can make sure the download worked correctly.
The only negative aspect of testing an iso/img fresh install directly is that the upgrade script from the previous version to the Testing version does not get evaluated in that approach but it can still provide good info on how the Testing version is performing or if there are any bugs in it.
Good luck either way you want to approach it.
Thank you very much @bonnietwin
I am learning many things thanks to you.
Now this aspect is also clear to me.
So, if I understand correctly, I could already test and download your patch? Are the “minor fixes” also there?
No. My patch has been submitted but it has not yet been reviewed and approved. After review and ok then the patch will be merged into the git repo. Then the next nightly build will create the new testing version. If you look in the directory with the iso/img files then there is a file that lists the changes that have been included in that version. I can’t remember the name of the file but you can look in the files and find out fairly easily.
Again thank you very much!!!
It is changelog.txt
I had seen this problem in a previous topic for CU173.
The only thing I understood is that there is a CPU strain under certain conditions. But what exactly does “cpufrequtils” do?
Okay. It’s for monitoring. I will follow the theme closely as well. I’m interested in it 
.
It seems that in version 174 the problem with high CPU and memory load by openvpn-authenticator is solved
after stopped
after restarting
after reconnecting red0
That was already fixed in the release version of Core Update 173. The problem with the update.sh script in CU173 Testing was identified and fixed.
But the n2n connection process is still active after stopping OpenVPN Server
CU173
CU174 Development Build: master/11f4726b
and I can connect to hosts on the remote network
Is it a bug or a feature? 
That is different to openvpn-authenticator.
I am not familiar at all with n2n openvpn so don’t know if that is expected or not.
If n2n connections should also be stopped when openvpn is disabled then that sounds like a bug that should be raised.
Maybe some else familiar with n2n can comment on this.
N2N uses a different instance (different port, different tun device, …) then the OpenVPN Server. To stop the N2N connection you can disable it in “Client Status and Control” by unchecking the hock of the corresponding connection → git.ipfire.org Git - ipfire-2.x.git/blob - html/cgi-bin/ovpnmain.cgi .
Best,
Erik
As Erik mentioned, uncheck the checkbox in your net to net connection line.
