On 30 Mar 2022, at 16:59, Valters Jansons valter.jansons@gmail.com wrote: On Wed, Mar 30, 2022 at 6:36 PM Michael Tremer michael.tremer@ipfire.org wrote:
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.
Got around to testing it this morning, and can confirm the commit resolves the export issue. Thank you!
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.
That is nice to hear, and is very appreciated. Of course if we see something more, I will report.
Again - thank you!
-Valters