Bug 191331

Further investigation:
* iptables modules but no kernel IPv4 module: connlimit, rpc, unclean, MIRROR, 
TARPIT and TRACE.
* Kernel IPv4 modules but no iptables module: connbytes, dccp, string and 
CLUSTERIP.
Some missing iptables modules are due to missing header files 
e.g. /usr/include/linux/netfilter_ipv4/ipt_string.h at iptable build time as 
they are not part of glibc-kernheaders.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

I have check the kernel-2.6.18-1.2200.fc5 and iptables-1.3.5-1.2 sources and 
module libraries and the problem remains.

The following have kernel modules but no iptables modules:
    CLUSTERIP, conbytes, dccp, quota and string.
This appears to be due to the definition of "KERNEL_DIR=/usr" in the iptables 
spec file. This path is used to test for the presence of patches in the kernel 
source tree and "/usr" is providing false information.

The following have iptables modules by no kernel modules:
    connlimit, MIRROR, rpc, TARPIT, TRACE and unclean.
To include these would require a decision as to their use within FC5. Kernel 
patches would need to be made to include them or patches made to the iptables 
package to exclude them.

Reassign/move/copy/split bug to iptables?

I have same kernel and iptables version as DaveG has.

Additional information:
- statistics kernel module exists, but not iptables module

(and there are missing lots of extensions mentioned on man pages: time, nth,
random, fuzzy, account...)

Iptables 1.3.5 should be rebuild to match kernel modules. How about iptables 1.3.6?

userspace should not be referencing any modules that need kernel patches.  We
have enough bugs with the stuff that's already in-tree, adding out-of-tree
patches is a quick way to drive me completely insane.

Created attachment 139054 [details]
iptables module status

Table of iptables extension modules and current status.

In an attempt to move things forward...

THE PROBLEM
1 iptables does not build the way it should. This is due to the KERNEL_DIR used
  in the iptables.spec file being set to "/usr" rather than to a valid kernel
  source tree. Test scripts are used to detect the availability of kernel
  facilities and arrive at the wrong conclusion.
2 Some of the kernel netfilter modules assumed by iptables are not in the
  Fedora kernel package.

SUGGESTED RESOLUTION:
1 Decide on the set of required IPv4/IPv6 modules and facilities for each
  architecture.
2 Update the kernel and/or iptables builds to include only the required module
  set.

NOTES:
The optional iptables features provided by patch-o-matic may include patches to
kernel source, this will require further review and inclusion in the kernel
patch set if required.
I don't use IPv6, so this will need further checking.

IPTABLES BUILD OPTIONS:
1 Make kernel source a build requirement and set KERNEL_DIR in iptables.spec
  to use the source.
  Is there any RPM mechanism to require a SOURCE package?
  The close relationship between iptables and the kernel will remain a problem
  if packages are to remain independent.
2 Make kernel-devel a build requirement and set KERNEL_DIR in iptables.spec
  to use the kernel module tree (/lib/modules/<kver>/build?).
  Will still require some modifications to iptables test files to always check
  for header files rather than C source files (extensions/.*{-test,-test6}).
  Each change would need to be verified to ensure that the test was valid and, 
  ideally, propagated upstream.
3 Modify all test scripts to look directly for a kernel module rather than
  header or source files.
4 Bypass the iptables optional test/build mechanism (extensions/Makefile) by
  setting the module list variables statically to match the kernel source.

OPINION:
* The range of modules and facilities are a matter for Fedora policy makers.
* iptables may require closer coupling to the kernel package to ensure that
  feature sets remain in step. But, since modules have been out-of-step since
  FC5 (or before), close coupling may not be an serious issue.
* Initial changes should be limited to bringing iptables in-line with the
  current kernel. i.e. within iptables:
    add: CLUSTERIP quota statistic
    remove: connlimit MIRROR rpc TARPIT TRACE unclean
* The simples solution would appear to be to hard-code the modules set in the
  iptables extensions/Makefile.

Also added three attachments: A sample iptables patch and two scripts to 
highlight modules differences between iptables and kernel.

Created attachment 159745 [details]
Suggested patch for iptables

Change default modules sets to match kernel and hard code the list of optional
modules.

Created attachment 159746 [details]
Identify 'missing' iptables modules.

Created attachment 159747 [details]
Identify 'missing' kernel modules.

This has been fixed in iptables-1.3.8-2 in rawhide and for testing packages in
FC-6 and F-7.

I am sorry, but FC-5 is EOL.

Closing as "WONTFIX"