From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Next steps of IPFire Location Date: Fri, 27 Nov 2020 16:48:44 +0000 Message-ID: <7E8F0907-F67A-41D9-ACFE-A5EAC5681962@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8533164872160395337==" List-Id: --===============8533164872160395337== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I have just pushed the required changes to fix the segmentation fault on 32 b= it machines. That was unfortunately caused by an integer underflow. I am not sure if anyone is running a 32 bit system in production, but I would= like to hear how well this is performing on those. Best, -Michael > On 27 Nov 2020, at 08:03, Stefan Schantl wrot= e: >=20 > Hello Michael, >=20 > I've installed the latest experimental update on my productive IPFire > system (IPFire Mini Appliance) and performed the export test again. >=20 > Here are the results: >=20 > [root(a)gate ~]# cat /etc/system-release > IPFire 2.25 (x86_64) - core153 Development Build: next/7adacda0 >=20 > [root(a)gate ~]# time location export --directory=3D/tmp --format=3Dxt_geoip >=20 > real 1m38.759s > user 1m37.743s > sys 0m0.390s >=20 > Best regards, >=20 > -Stefan >> Ladies and gentlemen, >>=20 >> After days and days of looking into this, and neglecting all the more >> important things I should be doing, I have updated libloc in the >> testing tree. >>=20 >> The good news is that I think that I have fixed the issue. I would >> like you all to check this for me if you could :) >>=20 >> The bad news is that the reason the output was incorrect was that the >> more complicated code path was not being used when it was required. >> This has been fixed now and it is actually fast enough I think. That >> again has to be tested. >>=20 >> If you all would repeat the last test with the updated version as >> soon as it finishes its build. >>=20 >> It will run for many many minutes, if not an hour. I want to know >> that figure. We will bring it down. >>=20 >> Best, >> -Michael >>=20 >>> On 23 Nov 2020, at 11:16, Michael Tremer >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Yes, I can confirm this. The subnets returned are not unique. >>>=20 >>> -Michael >>>=20 >>>> On 22 Nov 2020, at 11:59, Peter M=C3=BCller >>>> wrote: >>>>=20 >>>> Hello *, >>>>=20 >>>> I just stumbled across a strange issue on my testing machine >>>> strongly reminding me of a problem with the xt_geoip module if we >>>> printed the location database contents non-planar: >>>>=20 >>>> For debugging and monitoring reasons, a NRPE job pinging >>>> ping.ipfire.org (which resolves to 81.3.27.38) is executed >>>> periodically. Since a few hours, this job fails due to ICMP >>>> packets to this IP address being dropped by the outgoing firewall >>>> engine. >>>>=20 >>>> Its policy is set to "drop", with a rule allowing ICMP traffic to >>>> DE. While "location lookup 81.3.27.38" correctly returns DE for >>>> the prefix 31.8.0.0/18, it seems as the xt_geoip module did not >>>> get that and misclassifies this IP address. >>>>=20 >>>> Is somebody able to verify or falsify this issue on Core >>>> Development Build 153? >>>>=20 >>>> Thanks, and best regards, >>>> Peter M=C3=BCller >=20 --===============8533164872160395337==--