Description of problem: FC5 kernel (netfilter) and iptables packages include a different set of modules. Version-Release number of selected component (if applicable): kernel-smp-2.6.16-1.2111_FC5 iptables-1.3.5-1.2 How reproducible: ls /lib/modules/`uname -r`/kernel/net{,/ipv4}/netfilter ls /lib/iptables Steps to Reproduce: Try any of the missmatched modules or a complex, generated firewall script e.g.: iptables -A INPUT -m unclean -j LOG iptables -A INPUT -m string ... etc. Actual results: Either iptables syntax errors or library/module errors e.g. iptables: Unknown error 4294967295 Expected results: iptables modules should match the kernel modules. Additional info: Run patch-o-matic-ng on kernel and iptables packages? May have security implications for some firewall configurations (iptables- reload may fail on boot, especially after upgrade). May relate to a number of other iptables bug reports.
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"