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 139 (testing) report Date: Thu, 12 Dec 2019 19:35:00 +0000 Message-ID: <870f0e4f-d807-f088-76c9-a876b3eea335@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0880428453027013859==" List-Id: --===============0880428453027013859== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello *, upcoming Core Update 139 (testing, see: https://blog.ipfire.org/post/ipfire-2= -23-core-update-139-is-available-for-testing) is running here for about 24 hours by now, and caused major trouble especially related to IPsec. First, the update did not triggered a "reboot is requried" message, which is obligatory since we are shipping some new Intel microcodes. Those need a rebo= ot in order to be loaded into the CPU. Second, I forgot to execute /usr/local/bin/sshctrl during update (update.sh), so user settings were not applied to the SSH configuration. My fault (again). Third, IPsec N2N connections are not set up automatically after rebooting alt= hough they were configured to be. Worse, something seems to go seriously wrong, as = traffic to a destination IP address on the other side of the IPsec connection is emit= ted directly to the internet. Surprisingly enough, connections initiated from the remote network behind an = IPsec connection succeed and response packets apparently are sent back through the = tunnel. Reason for this is unknown; as far as I am concerned, this Core Update is not= yet ready. I will open bug tickets for the problems mentioned above (and others, if nece= ssary). Output of "uname -a" for reference purposes: > [root(a)maverick ~]# uname -a > Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 I= ntel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux Thanks, and best regards, Peter M=C3=BCller --===============0880428453027013859==--