From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: location@lists.ipfire.org Subject: Core Update 153 (testing) report Date: Mon, 14 Dec 2020 21:38:07 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2913450480220685041==" List-Id: --===============2913450480220685041== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello development folks, hello location folks (CC'ed), Core Update 153 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-= update-153-available-for-testing) is running here for a few days by now without any known issues so far. After downloading a recent (Saturday or later) location database, I can confi= rm its data to be less inaccurate by now. The output of the following commands are an ideal measurement for Q&A= purposes since they differ from older location databases which used the (crappy) delegated-extended-latest fi= les, which we now only need for regions covered by ARIN and LACNINC, as they do not publish better data: > [root(a)maverick ~]# location lookup 51.15.0.1 > 51.15.0.1: > Network : 51.15.0.0/17 > Country : Netherlands > Autonomous System : AS12876 - ONLINE S.A.S. > [root(a)maverick ~]# location lookup 51.15.129.1 > 51.15.129.1: > Network : 51.15.0.0/16 > Country : France > Autonomous System : AS12876 - ONLINE S.A.S. > [root(a)maverick ~]# location lookup 95.216.0.1 > 95.216.0.1: > Network : 95.216.0.0/17 > Country : Finland > Autonomous System : AS24940 - Hetzner Online GmbH Location filter has not been tested, but since we built safeguards into it in= Core Update 152 and implemented additional checks to exclude bogus RIR data as best as we can - not to mentio= n Michael spending weeks on re- implementing a fast (!) algorithm for dumping libloc's tree planar for xt_geo= ip module, which cannot reliably handle overlapping networks -, I do not expect any issues here. As mentioned earlier, I am unable to reproduce Suricata 6.0 eating up an unre= asonable amount of CPU time on my testing machine, which runs on an Intel N3150, thus apparently not being a= ffected by the problem especially virtualised users seem to experience. Actually, CPU load is a bit lower than = it was in Core Update 152, while usual network load and system resources remained unchanged. OpenVPN road-warrior connections were reported to be notably faster, but I co= uld not test them by myself for technical reasons. Thanks to Michael again for cleaning up this mess (as expl= ained in commit https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3Dd6989b4b0b42937485f= 5008cda6cdd730275f1ec). :-) 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) I look forward to the release of this Core Update, as it finally comes with a= n location database as less inaccurate (given the rather patchy RIR data, I try to avoid the term "accuracy" here) a= s we could do with the data we have at hand. Thanks, and best regards, Peter M=C3=BCller P.S.: Reading Unbound's latest release note, I stumbled across re-using TCP a= nd TLS connections. In case this works as I expect it to do, this should make DNS over TCP (rather dull) and T= LS (more interesting in terms of privacy) significantly faster in Core Update 154. --===============2913450480220685041==--