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: Mon, 23 Nov 2020 11:16:51 +0000 Message-ID: In-Reply-To: <6b09eecd-f928-a760-d9fa-f2fc368e5fc9@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1702361071967402333==" List-Id: --===============1702361071967402333== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Yes, I can confirm this. The subnets returned are not unique. -Michael > On 22 Nov 2020, at 11:59, Peter M=C3=BCller wr= ote: >=20 > Hello *, >=20 > I just stumbled across a strange issue on my testing machine strongly remin= ding me of a problem with the xt_geoip module if we printed the location data= base contents non-planar: >=20 > For debugging and monitoring reasons, a NRPE job pinging ping.ipfire.org (w= hich resolves to 81.3.27.38) is executed periodically. Since a few hours, thi= s job fails due to ICMP packets to this IP address being dropped by the outgo= ing firewall engine. >=20 > 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. >=20 > Is somebody able to verify or falsify this issue on Core Development Build = 153? >=20 > Thanks, and best regards, > Peter M=C3=BCller --===============1702361071967402333==--