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

[Michael Tremer <michael.tremer@ipfire.org>]

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

Hello,

> On 30 Mar 2022, at 16:59, Valters Jansons <valter.jansons(a)gmail.com> wrote:
> 
> 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?

I don’t necessarily want to drop it, but since resources are scarce, I don’t see any reason to maintain something that nobody is using. Since you are using it, and because it works, I don’t see any reason to immediately drop it.

The database format isn’t 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 performance from :)

So, no worries that support for xt_geoip will go away. But please keep reporting any problems that you encounter.

Best,
-Michael

> -Valters