From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Core Update 158 (testing) report Date: Mon, 05 Jul 2021 19:53:37 +0200 Message-ID: <7b0dd02a-b899-5fff-2907-293605136f21@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1941075525479638846==" List-Id: --===============1941075525479638846== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello *, Core Update 158 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-= update-158-available-for-testing) is running here for about 24 hours by now. It introduced some minor issues du= ring 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/sshc= trl" - this is starting to get a bit embarrassing, but I guess its a good thing to be discovered while sti= ll being in QA. :-) (b) On my testing machine, installing the update required two attempts of run= ning 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, o= ccasionally 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 pro= perly, as described in https://lists.ipfire.org/pipermail/development/2021-March/009656.html a w= hile ago. I unfortunately never caught the root cause for this, but blamed an error somewhere in the Linu= x kernel. Bug #12563 sounds pretty related. After upgrading all IPFire machines to Core Update 157, the problem disap= peared (and I was happy). Surprisingly, it reappeared at least once after having upgraded _one_ system to Core Up= date 158. Since we did not ship a kernel in C158, this rules out Linux being the so= le root cause for this. I am starting to blame pppd as well, as it is the only piece of software changed in C15= 8 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=20 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=C3=BCller --===============1941075525479638846==--