From: Michael Tremer <michael.tremer@ipfire.org>
To: location@lists.ipfire.org
Subject: Re: [0.9.12] export --format xt_geoip: (25, 'Inappropriate ioctl for device')
Date: Wed, 30 Mar 2022 16:36:46 +0100 [thread overview]
Message-ID: <034495A8-9200-47CF-854D-D8C2B4F39C31@ipfire.org> (raw)
In-Reply-To: <6A45D93F-D405-450A-A9EF-EDA962FF5CBE@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
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.
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?
-Michael
> On 29 Mar 2022, at 16:03, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>
> Hello Valters,
>
> Yes I can reproduce this on Debian 11 with the latest build from the Debian repository.
>
> -Michael
>
>> On 29 Mar 2022, at 15:43, Valters Jansons <valter.jansons(a)gmail.com> wrote:
>>
>> I am wondering if maybe it has been broken previously but we never picked it up. Say, from ce1e53c "export: Sightly refactor export logic" in some magical case.
>>
>> Michael, in any case, can you repro what I am seeing on the current release?
>>
>> -Valters
>
next prev parent reply other threads:[~2022-03-30 15:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+sCei3rpFGm=5QYxP-tsG4bjZL6+NQHG07XG540QGVkng5U4w@mail.gmail.com>
2022-03-29 15:03 ` Michael Tremer
2022-03-30 15:36 ` Michael Tremer [this message]
2022-03-30 15:59 ` Valters Jansons
2022-03-30 16:04 ` Michael Tremer
[not found] <CA+sCei11=+qTjjeWT+D0_8VRJZQhg+mwZn_BGcMmfSxHriKViw@mail.gmail.com>
2022-03-29 14:10 ` Michael Tremer
2022-03-29 14:16 ` Valters Jansons
2022-03-29 14:25 ` Valters Jansons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=034495A8-9200-47CF-854D-D8C2B4F39C31@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=location@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox