Re: [0.9.12] export --format xt_geoip: (25, 'Inappropriate ioctl for device')

[Valters Jansons <valter.jansons@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

On Wed, Mar 30, 2022 at 6:36 PM Michael Tremer
<michael.tremer(a)ipfire.org> wrote:
>
> Hello Valters,
>
> Here is the fix:
>
>   https://git.ipfire.org/?p=location/libloc.git;a=commitdiff;h=47b55e7060f6714889d2a8a45dd01e3452e2db38
>
> The error was shown incorrectly because this was the last syscall that failed (but it was executed by Python and not us).
>
> 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.
>
> Please confirm to me whether or not this patch resolves the problem.

Michael, thank you for finding the bug! I will rebuild with that
commit applied, and try to test later today.

> 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’t need the code any more which is probably why I didn’t catch this problem earlier - I have added a small test though. Writing more tests, better development documentation and returning better error codes in some places is on our TODO list, but we are incredibly lacking time and human resources to allocate to this. Can you help?

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?

-Valters