Re: Next steps of IPFire Location

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

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

Hello,

I have just pushed the required changes to fix the segmentation fault on 32 bit 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 <stefan.schantl(a)ipfire.org> wrote:
> 
> 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
>