SNAT and MASQUERADE, at mimimum, are broken if iptables isn't recompiled against a newly-installed 2.4.21 kernel. I can't find anything in either the vanilla-sources or iptable ebuilds that recognizes or notifies about this dependency. Reproducible: Always Steps to Reproduce: 1. Upgrade to 2.4.21 (vanilla-sources) with SNAT and/or MASQUERADE included 2. Run a command like "iptables -t nat -A POSTROUTING -o etho -j MASQUERADE" (or SNAT) 3. Get an error message ("iptables: Invalid argument") and no joy with SNAT or MASQUERADE (although many other iptables commands work fine).
*** This bug has been marked as a duplicate of 1991 ***
Why not as a partial solution until the very old bug 1991 is addressed have the ebuilds for downloading new kernels provide the information to stdout that the user should emerge iptables again afterwards if installed? That informational mechanism is already in place. A solution to 1991 would be better. But this is an unusual situation where updating kernels in the 2.4 serious prior to 2.4.21 did not require recompiling iptables. At 2.4.21 it does, and with no notice of this the user can have to go to considerable trouble to discover what went wrong, when a simple notice in the ebuild that downloads the kernel source would have prevented that trouble.
This isn't really a bug as kernel modules have to be rebuilt when moving other kernels. The same applies both to iptables, NVIDIA drivers, I2C, ... ... ... and thus forth. NOTABUG.
plasmaroo fails to understand the bug report - perhaps I wasn't clear. It's not about kernel modules - it's about the iptables ebuild, which contains the utilities for loading firewall rules, irrespective of whether iptables/netfilter support has been built into the kernel or built as kernel modules. The bug is that the iptables package itself has to be freshly emerged after building and installing the new kernel, or else some firewall rules will unexpectedly and inexplicably fail to load correctly. Again, building modules does not cause the iptables package to be rebuilt, so plasmaroo hasn't understood the problem. Partial failure of the firewall is a serious security risk, as well as causing other sorts of networking failures in production environments. This bug still needs to be addressed.
In which case I'm reassigning this to bug-wrangling as I see no kernel problems here and the bugs seem to lie in the iptables ebuild...?
There is no bug in the iptables ebuild. This problem exists even if building the kernel and iptables by hand - you can find discussion of it on the netfilter list. The kernel code that supports iptables changed significantly enough in version 2.4.21 that iptables needs to be rebuilt after upgrading the kernel. This is a dependency therefore that the kernel ebuild needs to somehow address. I think I have seen a informational message added there since this was first reported? Maybe that's all that can be done. Note iptables did not need to be rebuilt to keep working from early in the 2.4 series through 2.4.20 (at least not in my experience) - this appears to be specific to going from <= 2.4.20 to a higher kernel version. So having a new kernel build always rebuild iptables might be overkill.
what Whit Blauvelt says. You'll need to recompile iptables at every major version change, due to code and structure changes. If it just works, you simply had luck.
Markus, If what you say is true, then providing someone hasn't added this information to the Gentoo docs since I last looked, it is still a _documentation bug_. My own best knowledge is that it's not true - that through a number of major version changes the netfilter code and structures stays largely the same, but occassionally (e.g. between 2.4.20 and 2.4.21) undergoes changes major enough to require recompling iptables. But I haven't audited the code - I'm just going by the netfilter list discussions and personal experience. Still, the best resolution of the bug may be to treat it as a documentation bug until it is added someplace prominent enough in the Gentoo docs as to make it common knowledge. On a number of systems I run (with different distros, although I always compile my own kernel.org or -ac kernels) iptables did not need to be recompiled between early in the 2.4 series and 2.4.21, and I use many of its features. (Similarly ipchains stayed good through the 2.2 series.) So it will not be common knowledge from experience for those going from <= 2.4.20 that it needs to be recompiled, and it would be good to make sure this knowledge is shared, wouldn't it, considering the security and network stability issues?
aliz, please add an einfo section to iptables
Added small einfo
