From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Core Update 133 (testing) report
Date: Mon, 17 Jun 2019 16:57:20 +0100
Message-ID: <709E7FA5-1F1D-464A-A687-FCD65821D4AA@ipfire.org>
In-Reply-To: <2a5ccb4c-c62d-a4ec-357e-d220f5109356@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4869463732835849057=="
List-Id: <development.lists.ipfire.org>

--===============4869463732835849057==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hey,

Long list, but good finds.

> On 16 Jun 2019, at 15:26, Peter M=C3=BCller <peter.mueller(a)ipfire.org> wr=
ote:
>=20
> Hello *,
>=20
> this is just a quick testing report for upcoming Core Update 133
> (see: https://blog.ipfire.org/post/ipfire-2-23-core-update-133-ready-for-te=
sting).
>=20
> The following parts of IPFire seem to work correctly:
> - DDNS
> - Squid proxy (including upstream proxy)
> - OpenVPN (RW connections only)
> - Suricata
>=20
> Regarding Strongswan/IPsec, I experience tunnel crashes after
> approximately 30 minutes. However, Strongswan still logs INFORMATIONAL
> packets, which can be parsed successfully, too.
>=20
> Restating the connections manually via WebUI works, but leaves
> log messages like these:
>> Jun 16 16:13:42 maverick charon: 03[ENC] parsed CREATE_CHILD_SA response 2=
 [ N(NO_PROP) ]=20
>> Jun 16 16:13:42 maverick charon: 03[IKE] received NO_PROPOSAL_CHOSEN notif=
y, no CHILD_SA built=20
>> Jun 16 16:13:42 maverick charon: 03[IKE] failed to establish CHILD_SA, kee=
ping IKE_SA=20

I assume that this is now fixed with the patch that you sent?

> At the moment, I have no idea what the reason of this might be.
> Using certificate-based N2N connection with Chacha20/Poly1305 and
> Curve25519.
>=20
> Regarding CPU load data, I notice a decrease in IRQ usage,
> probably because of Hyperscan and Suricata changes.

No, that shouldn=E2=80=99t decrease IRQ at all. You would receive the same am=
ount of packets and the scanning wouldn=E2=80=99t show up as interrupt usage.

> I can confirm missing translations are now present.
>=20
> Interestingly, spectre-meltdown-checker thinks my testing hardware
> is vulnerable to Spectre 3a:
>> CVE-2018-3640 aka 'Variant 3a, rogue system register read'
>> * CPU microcode mitigates the vulnerability:  NO=20
>>> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate t=
his vulnerability)

I have seen systems where this as mitigated. So it could be the the microcode=
 doesn=E2=80=99t support the mitigation?

> /var/log/bootlog however, states current microcodes have been loaded:
>> [    0.000000] microcode: microcode updated early to revision 0x368, date =
=3D 2019-04-23
>> [    0.000000] Linux version 4.14.121-ipfire (root(a)helena.ipfire.org.ipf=
ire.org) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 22 13:45:15 GMT 2019
>=20
> (Two glitches here: "helena.ipfire.org.ipfire.org" and GCC 7.3.0 .
> I thought the toolchain now uses GCC 8.0?!)
>=20
> Besides of the IPsec issue, which needs to be investigated further,
> everything seems to work correctly.
>=20
> Thanks, and best regards,
> Peter M=C3=BCller
> --=20
> The road to Hades is easy to travel.
> 	-- Bion of Borysthenes


--===============4869463732835849057==--