Re: Core Update 133 (testing) report

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]

Hey,

Long list, but good finds.

> On 16 Jun 2019, at 15:26, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> 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-testing).
> 
> The following parts of IPFire seem to work correctly:
> - DDNS
> - Squid proxy (including upstream proxy)
> - OpenVPN (RW connections only)
> - Suricata
> 
> Regarding Strongswan/IPsec, I experience tunnel crashes after
> approximately 30 minutes. However, Strongswan still logs INFORMATIONAL
> packets, which can be parsed successfully, too.
> 
> 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) ] 
>> Jun 16 16:13:42 maverick charon: 03[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built 
>> Jun 16 16:13:42 maverick charon: 03[IKE] failed to establish CHILD_SA, keeping IKE_SA 

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.
> 
> Regarding CPU load data, I notice a decrease in IRQ usage,
> probably because of Hyperscan and Suricata changes.

No, that shouldn’t decrease IRQ at all. You would receive the same amount of packets and the scanning wouldn’t show up as interrupt usage.

> I can confirm missing translations are now present.
> 
> 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 
>>> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

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

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