The iptables initscript assumes that tables called "nat" and "mangle"
exist. They may not be present in all kernels, though. When they are
missing, the script fails.
The script should not tickle any table that isn't known to the kernel. The
list of known tables is available in "/proc/net/ip_tables_names", which is
already examined elsewhere in the same script.
Note that this problem was mentioned in bug #29104, filed by someone else.
However, that report also described a completely different problem which
has since been fixed. To avoid confusion, I'm filing this as a distinct
report. QA is much easier when there is only one problem per bug report.
I am seeing this problem with the script that is part of iptables-1.2.0-10.
Created attachment 12142 [details]
one possible approach to fixing this bug
I've attached a patch above that suggests one possible way of fixing this bug.
The general idea is to create an "iftable" function that takes the name of a
table and an iptables command line which is to be run only if the given table
exists. It ends up looking at /proc/net/ip_tables_names quite a few times, but
that doesn't seem to be a performance problem in practice.
Most of the problems I reported are fixed, then, by using "iftable" instead of
calling "iptables" directly. The one exception is the "status" handler. In
this case, it seemed wiser to make the code more generic, and have it display
all tables listed in /proc/net/ip_tables_names.
I suppose the other option would be to split out the filter, nat, and mangle
tables into their own initscripts. Each one could be controlled by a distinct
"chkconfig" option, so that each system's administrator could explicitly
activate or deactivate just the tables of interest.
Fixed since 1.2.0-10
According to <firstname.lastname@example.org> this problem has been "fixed since 1.2.0-10".
However, that is exactly the version and release against which I filed this
report in the first place. The problem has not been fixed since 1.2.0-10, and
is easily demonstrated using 1.2.0-10 on any machine that does not have the
mangle and nat tables.
Please reconsider the status of this bug. Note, as well, that there's already a
patch attached to this report that illustrates one reasonable way of fixing the
Hmm. Maybe there's some confusion here. When Bero wrote "Fixed since
1.2.0-10", did he mean that the bug had already been fixed going as far back as
1.2.0-10? Or did he mean that it had been fixed at some unspecified release
that happened after 1.2.0-10? If the former, I disagree. If the later, then I
eagerly await the arrival of this unspecified later release.
For the record, this bug is still present in iptables-1.2.1a, which shipped with
Red Hat 7.1. Perhaps someone should change the "Product" and "Version" fields?
I'm not sure if I have permission to do that.
And again, please consider applying the patch I attached earlier. It fixes this
problem quite cleanly. That patch was created for 1.2.0; I haven't checked to
see if it needs changes for 1.2.1a, but that shouldn't be hard.
I had added your patch and forgotten to send the package through the
buildsystem, therefore it was lost.
It's fixed for real in 1.2.2-3.
Bero claims that "It's fixed for real in 1.2.2-3". It is not. The problem
still appears in the iptables-1.2.2-3 RPM which is part of Red Hat's "roswell"
True, it was fixed only partially.
I've added the full fix in 1.2.4-1 (rawhide now, errata soon).