From: Herve Eychenne <rv@wallfire.org>
To: Henrik Nordstrom <hno@marasystems.com>
Cc: Netfilter Development <netfilter-devel@lists.netfilter.org>
Subject: Re: iptables-save counters on builtin chains not restored?
Date: Sun, 22 Aug 2004 22:14:30 +0200 [thread overview]
Message-ID: <20040822201430.GI4883@eychenne.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0408210143150.8001@filer.marasystems.com>
On Sat, Aug 21, 2004 at 02:01:44AM +0200, Henrik Nordstrom wrote:
> On Fri, 20 Aug 2004, Herve Eychenne wrote:
> >The side effect of this change will be that dump files created by new
> >iptables-save command (without -c) won't be restorable with old
> >iptables-restore (without -c).
> Are you sure? From what I can see this should work. I never specify
> counters in my iptables-restore input from what I can tell.. not on
> policies, not in rules. And it works just fine.
Probably you missed my rectification (sorry again) :
dump files created by new iptables-save command (without -c) won't be
restorable with old iptables-restore -c
^^^^
So there is no problem for the case you describe, right.
> iptables-restore -c without having counters specified in policies or
> custom chains complains,
According to me, it does not only complain, it crashes, because we
did not check the return of strtok and tried to parse counters whether
they are actually present or not. I fixed it already in my tree
(patch will be sent soon).
> but I never use this so I don't care, and what would the point be?
> What would break is reading in output from new iptables-save (with or
> without -c) using old iptables-restore -c.
Yes.
> >One thing that puzzles me is that old iptables-restore -c used to
> >restore old iptables-save (without -c) dumps without any complaints
> >about missing counters (for rules, as counters for builtin-chains were
> >dumped anyway).
> This is due to the parser nor caring if -c is specified or not when
> parsing the rules. It always parse the counters if there is any (in_table
> block), it then discards the result if -c is not specified.
I'm talking about chain counters (not rules), and IIRC these counters
were only parsed if -c was specified (memset of the struct to 0 otherwise).
Like I said, the issue was more that counters were tried to be parsed
even if they were lacking (->coredump).
But there is not much point in discussing this very longer... :-)
> >So I guess new iptables-restore -c should act likewise, that is
> >restore new iptables-save dumps (without -c) without error, but shouldn't
> >it at least issue a warning about the lack of the expected counters?
> Why? Is there a problem with reading a missing counter as an implicit
> zero?
It depends on your personnal policies. When I specify something like -c,
it is hardly by chance, and I tend to consider that trying (on purpose)
to restore something that actually does not exist is at least strange.
So I would personally go for a warning message (median solution),
but that's only a matter of how rigorous you expect the tools to be.
Herve
--
_
(°= Hervé Eychenne
//)
v_/_ WallFire project: http://www.wallfire.org/
prev parent reply other threads:[~2004-08-22 20:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-17 21:18 iptables-save counters on builtin chains not restored? Herve Eychenne
2004-08-19 10:13 ` Harald Welte
2004-08-20 14:36 ` Herve Eychenne
2004-08-20 16:08 ` Herve Eychenne
2004-08-21 0:01 ` Henrik Nordstrom
2004-08-22 20:14 ` Herve Eychenne [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040822201430.GI4883@eychenne.org \
--to=rv@wallfire.org \
--cc=hno@marasystems.com \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.