From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: location@lists.ipfire.org Subject: Re: Next steps of IPFire Location Date: Wed, 25 Nov 2020 20:24:19 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6544287397470457208==" List-Id: --===============6544287397470457208== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ladies and gentlemen, After days and days of looking into this, and neglecting all the more importa= nt 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 a= ll to check this for me if you could :) The bad news is that the reason the output was incorrect was that the more co= mplicated code path was not being used when it was required. This has been fi= xed 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 wrot= e: >=20 > Hi, >=20 > Yes, I can confirm this. The subnets returned are not unique. >=20 > -Michael >=20 >> On 22 Nov 2020, at 11:59, Peter M=C3=BCller w= rote: >>=20 >> Hello *, >>=20 >> I just stumbled across a strange issue on my testing machine strongly remi= nding me of a problem with the xt_geoip module if we printed the location dat= abase contents non-planar: >>=20 >> 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, th= is job fails due to ICMP packets to this IP address being dropped by the outg= oing firewall engine. >>=20 >> Its policy is set to "drop", with a rule allowing ICMP traffic to DE. Whil= e "location lookup 81.3.27.38" correctly returns DE for the prefix 31.8.0.0/1= 8, it seems as the xt_geoip module did not get that and misclassifies this IP= address. >>=20 >> Is somebody able to verify or falsify this issue on Core Development Build= 153? >>=20 >> Thanks, and best regards, >> Peter M=C3=BCller >=20 --===============6544287397470457208==--