Hello Arne,

Thank you for spotting this.

I have fixed the issue with some of the networks not being sorted correctly. Since this has affected performance slightly, the code has now become slightly faster again.

Regarding the 32 bit issue: This is a pain to debug now because I do not have a working 32 bit build environment with a debugger. I am compiling this now and I will work on it tomorrow.

Your export of A1 was incorrect because it wasn’t exported at all. That must have been old data because I forgot to copy the flags, too.

Best, -Michael

On 26 Nov 2020, at 07:51, Arne Fitzenreiter arne_f@ipfire.org wrote:

Bad news with current nightly. The export segfault on 32bit

Also the exported data on RPi3 was still not in the correct order. In my export the fourth entry of A1.ipv4 is lower than the third.

Arne

Am 2020-11-25 21:24, schrieb Michael Tremer:

...

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