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@gate ~]# cat /etc/system-release IPFire 2.25 (x86_64) - core153 Development Build: next/7adacda0
[root@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@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@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