Core Update 133 (testing) report

Core Update 133 (testing) report

[Peter Müller]

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

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 

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.

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)

/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

Re: Core Update 133 (testing) report

[Peter Müller]

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

Hello *,

just some minor corrections and additions...

> 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
By the way: I am currently observing a ton of scans coming from 92.118.37.0/24 .
Just in case anyone is interested in. :-/
> [...]
> 
> /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?!)Since we did not ship an updated Linux kernel, I guess this cannot
say "GCC 8.x" yet. Sorry.
> [...]

Thanks, and best regards,
Peter Müller
-- 
The road to Hades is easy to travel.
	-- Bion of Borysthenes

Re: Core Update 133 (testing) report

[Arne Fitzenreiter]

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

On 2019-06-16 16:47, Peter Müller wrote:
> Hello *,
> 
> just some minor corrections and additions...
> 
>> 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
> By the way: I am currently observing a ton of scans coming from 
> 92.118.37.0/24 .
> Just in case anyone is interested in. :-/
>> [...]
>> 
>> /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?!)Since we did not ship an 
>> updated Linux kernel, I guess this cannot
> say "GCC 8.x" yet. Sorry.
If you are using the 32bit PAE Kerel this is still compiled with 7.3.0 
(core131).

Arne

Re: Core Update 133 (testing) report

[Peter Müller]

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

Hello Arne,

>>>
>>> /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?!)Since we did not ship an updated Linux kernel, I guess this cannot
>> say "GCC 8.x" yet. Sorry.
> If you are using the 32bit PAE Kerel this is still compiled with 7.3.0 (core131).

I am running a x86_64 kernel on this system.

Thanks, and best regards,
Peter Müller
-- 
The road to Hades is easy to travel.
	-- Bion of Borysthenes

Re: Core Update 133 (testing) report

[Michael Tremer]

[-- 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