Re: Next steps of IPFire Location

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

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

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
>