From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Schantl <stefan.schantl@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Next steps of IPFire Location
Date: Fri, 27 Nov 2020 09:03:51 +0100
Message-ID: <b124aedd3cdb62879774a5ff36a2ec5b9fbf2c2f.camel@ipfire.org>
In-Reply-To: <B3711D15-E056-4220-8539-CDD04DFA57B1@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5983479188947011721=="
List-Id: <development.lists.ipfire.org>

--===============5983479188947011721==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hello Michael,

I've installed the latest experimental update on my productive IPFire
system (IPFire Mini Appliance) and performed the export test again.

Here are the results:

[root(a)gate ~]# cat /etc/system-release
IPFire 2.25 (x86_64) - core153 Development Build: next/7adacda0

[root(a)gate ~]# time location export --directory=/tmp --format=xt_geoip

real	1m38.759s
user	1m37.743s
sys	0m0.390s

Best regards,

-Stefan
> Ladies and gentlemen,
> 
> 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.
> 
> 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 :)
> 
> 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.
> 
> If you all would repeat the last test with the updated version as
> soon as it finishes its build.
> 
> It will run for many many minutes, if not an hour. I want to know
> that figure. We will bring it down.
> 
> Best,
> -Michael
> 
> > On 23 Nov 2020, at 11:16, Michael Tremer <michael.tremer(a)ipfire.org
> > > wrote:
> > 
> > Hi,
> > 
> > Yes, I can confirm this. The subnets returned are not unique.
> > 
> > -Michael
> > 
> > > On 22 Nov 2020, at 11:59, Peter Müller <peter.mueller(a)ipfire.org>
> > > wrote:
> > > 
> > > Hello *,
> > > 
> > > 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:
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > Is somebody able to verify or falsify this issue on Core
> > > Development Build 153?
> > > 
> > > Thanks, and best regards,
> > > Peter Müller


--===============5983479188947011721==--