From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valters Jansons To: location@lists.ipfire.org Subject: Re: [0.9.12] export --format xt_geoip: (25, 'Inappropriate ioctl for device') Date: Wed, 30 Mar 2022 18:59:23 +0300 Message-ID: In-Reply-To: <034495A8-9200-47CF-854D-D8C2B4F39C31@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3139398165568825014==" List-Id: --===============3139398165568825014== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2022 at 6:36 PM Michael Tremer wrote: > > Hello Valters, > > Here is the fix: > > https://git.ipfire.org/?p=3Dlocation/libloc.git;a=3Dcommitdiff;h=3D47b55e= 7060f6714889d2a8a45dd01e3452e2db38 > > The error was shown incorrectly because this was the last syscall that fail= ed (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 b= ecause 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 f= or 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 this= problem earlier - I have added a small test though. Writing more tests, bett= er development documentation and returning better error codes in some places = is on our TODO list, but we are incredibly lacking time and human resources t= o 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 --===============3139398165568825014==--