Bug 106002 - Get "libipt_recent.so: cannot open shared object file" error when attempting to use recent module
Get "libipt_recent.so: cannot open shared object file" error when attempting ...
Product: Fedora
Classification: Fedora
Component: iptables (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2003-10-01 17:37 EDT by gary mcfall
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-23 10:21:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed spec changes (1.47 KB, patch)
2003-10-20 19:15 EDT, Michael Schwendt
no flags Details | Diff

  None (edit)
Description gary mcfall 2003-10-01 17:37:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b)
Gecko/20030516 Mozilla Firebird/0.6

Description of problem:
Getting this error when attempting to use the recent module (for example,
/sbin/iptables -A INPUT -m recent --name PROBER -j DROP):

iptables v1.2.8: Couldn't load match `recent':/lib/iptables/libipt_recent.so:
cannot open shared object file

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1./sbin/iptables -A INPUT -m recent --name PROBER -j DROP

Actual Results:  Get this error message:

iptables v1.2.8: Couldn't load match `recent':/lib/iptables/libipt_recent.so:
cannot open shared object file

Expected Results:  Initial command should have been accepted.

Additional info:
Comment 1 gary mcfall 2003-10-09 11:13:48 EDT
1) Steps taken before submitting the bug:

a - I Googled the problem, finding this site.  The originator of that post did
not reply with the distribution used.


b - Viewed files in lib/iptables (libipt_recent.so missing):

libipt_ah.so         libipt_mac.so         libipt_standard.so
libipt_conntrack.so  libipt_mark.so        libipt_state.so
libipt_DNAT.so       libipt_MARK.so        libipt_TARPIT.so
libipt_dscp.so       libipt_MASQUERADE.so  libipt_tcpmss.so
libipt_DSCP.so       libipt_MIRROR.so      libipt_TCPMSS.so
libipt_ecn.so        libipt_multiport.so   libipt_tcp.so
libipt_ECN.so        libipt_owner.so       libipt_tos.so
libipt_esp.so        libipt_physdev.so     libipt_TOS.so
libipt_helper.so     libipt_pkttype.so     libipt_ttl.so
libipt_icmp.so       libipt_REDIRECT.so    libipt_TTL.so
libipt_iplimit.so    libipt_REJECT.so      libipt_udp.so
libipt_length.so     libipt_rpc.so         libipt_ULOG.so
libipt_limit.so      libipt_SAME.so        libipt_unclean.so
libipt_LOG.so        libipt_SNAT.so

2) I've changed the priority to high in hopes that this issue will be
reviewed/resolved prior to the 11-3 general availability release date for Fedora

Thanks in advance for your consideration and help.
Comment 2 gary mcfall 2003-10-20 15:57:10 EDT

To temporarily get around this problem, I deleted iptables, installed iptables
w/ recent support from another distro, copied the missing files into a different
directory, removed iptables, re-installed the original iptables, and copied the
missing files into the appropriate directory.  With that change, the recent
module is working correctly.

Please consider expediting resolution of this bug so that the recent module
works correctly with the General Release of Fedora Core.

Thanks in advance . . . .

Comment 3 Michael Schwendt 2003-10-20 19:15:32 EDT
Created attachment 95326 [details]
proposed spec changes

I think I've submitted a fix for this sometime between 1.2.5 and 1.2.7a
already, and the current spec file sets KERNEL_DIR, but to /usr instead of
/usr/src/linux-2.4 where the kernel source is located actually.

At build-time, iptables depends on kernel netfilter headers. There are hidden
script files which check for availability of kernel netfilter headers and then
enable/disable userspace extensions. Since it is looked in $KERNEL_DIR/net/...
and $KERNEL_DIR/include/... it does not suffice to compile iptables with
glibc-kernheaders or without kernel-source being installed.
Comment 4 Thomas Woerner 2003-10-23 10:21:19 EDT
Fixed in 1.2.8-13.

Note You need to log in before you can comment on or make changes to this bug.