From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: location@lists.ipfire.org Subject: Re: [0.9.12] export --format xt_geoip: (25, 'Inappropriate ioctl for device') Date: Wed, 30 Mar 2022 17:04:54 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0693118286619431984==" List-Id: --===============0693118286619431984== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 30 Mar 2022, at 16:59, Valters Jansons wrot= e: >=20 > On Wed, Mar 30, 2022 at 6:36 PM Michael Tremer > wrote: >>=20 >> Hello Valters, >>=20 >> Here is the fix: >>=20 >> https://git.ipfire.org/?p=3Dlocation/libloc.git;a=3Dcommitdiff;h=3D47b55e= 7060f6714889d2a8a45dd01e3452e2db38 >>=20 >> The error was shown incorrectly because this was the last syscall that fai= led (but it was executed by Python and not us). >>=20 >> The real reason is that the wrong prefix was used for IPv4 addresses which= resulted in a sanity check failing. However, I did not catch that very well = because it is incredibly unlikely to fail. >>=20 >> Please confirm to me whether or not this patch resolves the problem. >=20 > Michael, thank you for finding the bug! I will rebuild with that > commit applied, and try to test later today. >=20 >> I was also going to ask on this list whether people would rely on support = for xt_geoip. IPFire has just replaced xt_geoip with ipset and so we don=E2= =80=99t need the code any more which is probably why I didn=E2=80=99t catch t= his problem earlier - I have added a small test though. Writing more tests, b= etter development documentation and returning better error codes in some plac= es is on our TODO list, but we are incredibly lacking time and human resource= s to allocate to this. Can you help? >=20 > Due to organizational changes, I sadly don't have as much time for > external projects as I did before, and therefore cannot help out with > writing test cases. If you make the decision to drop the xt_geoip > format, we would of course be sad, but should be able to figure it > out. If that were the case, is there any expectation for database > backwards compatibility -- on how long the old versions would be able > to stay operational, and work with newer database files? I don=E2=80=99t necessarily want to drop it, but since resources are scarce, = I don=E2=80=99t see any reason to maintain something that nobody is using. Si= nce you are using it, and because it works, I don=E2=80=99t see any reason to= immediately drop it. The database format isn=E2=80=99t very flexible, so there is a lot of work to= do if that was to be changed. We have a mechanism built in for this, but we = need a very strong reason to touch this at all. This is where we get the perf= ormance from :) So, no worries that support for xt_geoip will go away. But please keep report= ing any problems that you encounter. Best, -Michael > -Valters --===============0693118286619431984==--