Hello *,

Core Update 158 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-update-158-available-for-testi...) is running here for about 24 hours by now. It introduced some minor issues during the update itself, and apparently brought back a quite annoying behaviour where VoIP calls sometimes cannot be established:

(a) The update script once again appears to be missing a "/usr/local/bin/sshctrl" - this is starting to get a bit embarrassing, but I guess its a good thing to be discovered while still being in QA. :-)

(b) On my testing machine, installing the update required two attempts of running Pakfire, while the Core Updates before went through straight-away (unless memories fail me). Not really a show-stopper, but a noticeable thing.

No offense intended, but the update took relatively long on my machine, occasionally returning 403's when refreshing the Pakfire CGI, but went all fine in the end. I guess it is a good idea not to undergo this during production hours, but within a scheduled maintenance window.

(c) For quite some time, I suffered from VoIP calls not being established properly, as described in https://lists.ipfire.org/pipermail/development/2021-March/009656.html a while ago. I unfortunately never caught the root cause for this, but blamed an error somewhere in the Linux kernel. Bug #12563 sounds pretty related.

After upgrading all IPFire machines to Core Update 157, the problem disappeared (and I was happy). Surprisingly, it reappeared at least once after having upgraded _one_ system to Core Update 158.

Since we did not ship a kernel in C158, this rules out Linux being the sole root cause for this. I am starting to blame pppd as well, as it is the only piece of software changed in C158 that smells relevant to me. On the other hand, this would have meant we suffer from this since March 2020 at least, where we successfully updated pppd the last time (https://blog.ipfire.org/post/ipfire-2-25-core-update-142-released).

Anyway: I will investigate, _finally_ try to get meaningful traces of it, and report back. I do not want to lose my functioning VoIP calls. :-)

I did not experience any issues while working with the CGIs so far. Stefans' and Michaels' endless efforts of squashing out bug #12616 seemed to be quite successful without breaking anything.

Tested IPFire functionalities in detail: - IPsec (N2N connections only) - Squid (authentication enabled, using an upstream proxy) - OpenVPN (RW connections only) - IPS/Suricata (with Emerging Threats community ruleset enabled) - Guardian - Quality of Service - DNS (using DNS over TLS and strict QNAME minimisation) - Dynamic DNS - Tor (relay mode)

Thanks, and best regards, Peter Müller