netfilter buglog - Jun 2014 - [Bug 960] New: iptables-save does not output the state of all tables

https://bugzilla.netfilter.org/show_bug.cgi?id=960

           Summary: iptables-save does not output the state of all tables
           Product: iptables
           Version: 1.4.x
          Platform: x86_64
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: iptables-save
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: jean-paul at hybridcluster.net
   Estimated Hours: 0.0


The iptables-save man page says:

   -t, --table tablename
      restrict output to only one table. If not specified, output includes all
available tables.

The actual behavior seems to be that if `-t` is not specified, the output
includes all tables for which there is any state (rules or non-zero packet/byte
counts).  Possibly this is what "available" is intended to mean here
but this
isn't clear (at least, to someone who isn't familiar with the internals
of how
tables are represented/implemented).

The unfortunate result of misunderstanding what `iptables-save` (without `-t`)
does is that in certain circumstances, the output will not include information
about all tables.  If `iptables-save` is being used along with
`iptables-restore` as part of a system to automatically roll-back any iptables
changes being made then this might result in changes being made that don't
get
rolled back.

It seems like it would be nice if the `iptables-save` output (without `-t`)
could actually include all tables, even if the state for some of those tables
is very boring.  For example, even if there are no rules or matched packets in
the `nat` table, it would be nice to have something like:

    # Generated by iptables-save v1.4.14 on Thu Jun 12 09:16:36 2014
    *nat
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT
    # Completed on Thu Jun 12 09:16:36 2014

in the output anyway.  Alternatively, just updating the documentation to
reflect the actual behavior would at least make it possible to avoid committing
this mistake after reading the documentation and observing the common behavior
(which is that most tables, most of the time, have either rules or non-zero
packet/byte counts and so appear in the output).

Thanks.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.