From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Next steps of IPFire Location Date: Thu, 26 Nov 2020 16:21:28 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0299070722074392138==" List-Id: --===============0299070722074392138== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 slightl= y 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=E2=80=99t exported at all. Th= at must have been old data because I forgot to copy the flags, too. Best, -Michael > On 26 Nov 2020, at 07:51, Arne Fitzenreiter wrote: >=20 > Bad news with current nightly. The export segfault on 32bit >=20 > 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 t= he third. >=20 > Arne >=20 > 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 wr= ote: >>> Hi, >>> Yes, I can confirm this. The subnets returned are not unique. >>> -Michael >>>> On 22 Nov 2020, at 11:59, Peter M=C3=BCller = wrote: >>>> Hello *, >>>> I just stumbled across a strange issue on my testing machine strongly re= minding me of a problem with the xt_geoip module if we printed the location d= atabase 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 ou= tgoing firewall engine. >>>> Its policy is set to "drop", with a rule allowing ICMP traffic to DE. Wh= ile "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 Bui= ld 153? >>>> Thanks, and best regards, >>>> Peter M=C3=BCller --===============0299070722074392138==--