Bug 255086 – net-analyzer/ipac-ng-1.31-r2 doesn't work with net-firewall/iptables-1.4.0-r1: no libipt_standard.so

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Jan Kundrát (RETIRED) 2009-01-15 19:18:34 UTC]

velbloud ~ # fetchipac -S
Couldn't load target `standard':/lib/iptables/libipt_standard.so: cannot open shared object file: No such file or directory

Indeed, there's no such file (while there was one with net-firewall/iptables-1.3.8-r3).

Looking at the source code, it seems that it wants to load some kind of a "generic" module from iptables, and fails in that attempt...

[Comment 1 Kevin 2009-03-18 04:41:11 UTC]

Well if there isn't a way to get iptables to build that .SO, there might not be a fix available that doesn't involve updating ipac-ng. AFAIK ipac-ng isn't being maintained anymore and so someone would have to take over and write a new version. I'm sure it would be welcomed though since this error started showing up on their mailing list a couple years ago.

[Comment 2 heady 2009-05-24 23:19:35 UTC]

This bug and bug #191582 are as far as I can tell are the same symptom.

Take this with a grain of salt as I'm new at this.

ipac-ng seems to try to preload iptables modules prior to setting up the chains and rules.

However, it appears that ipac-ng has been enhanced once or twice so in some cases it pulls the lib directory from the configure macros; whereas, in some places it has hard-coded filenames and paths.

Iptables has moved some of the shared .so files to /lib/xtables or /lib64/xtables and have changed the prefix from libipt_%s.so to libxt_%s.so.  Therefore, ipac-ng unmodified cannot find the shared .so files.

I initially thought it would be a simple task of hunting through and updating the configure paths and changing the hard-coded filenames and paths.  However, when I've done that I get:
./fetchipac -S
Couldn't load target `standard':/lib64/xtables/libxt_standard.so: undefined symbol: xtables_register_target

Now this is a bit of a guess...

But in iptables.c it seems that they have taken complete chucks of code from iptables-1.2.2 and use their own *.h files.  Therefore, in >iptables-1.3.8 like my iptables-1.4.2 the code chunks are different and I therefore get, the undefined symbols error from above.

I'm at a bit of a loss of what to try next - I might have a look at what some of the other distributions have done.  Or I might try to copy the code blocks over from iptables-1.4.2.

[Comment 3 Peter Volkov (RETIRED) 2011-05-24 14:11:51 UTC]

Package was dropped from the tree.