All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Eychenne <rv@wallfire.org>
To: Harald Welte <laforge@netfilter.org>,
	Netfilter Development <netfilter-devel@lists.netfilter.org>
Subject: Re: iptables-save counters on builtin chains not restored?
Date: Fri, 20 Aug 2004 16:36:17 +0200	[thread overview]
Message-ID: <20040820143617.GD4883@eychenne.org> (raw)
In-Reply-To: <20040819101314.GD3921@sunbeam.de.gnumonks.org>

On Thu, Aug 19, 2004 at 12:13:14PM +0200, Harald Welte wrote:

> On Tue, Aug 17, 2004 at 11:18:21PM +0200, Herve Eychenne wrote:

> > When fed with the result of iptables-save -c, iptables-restore -c
> > does not seem to restore counters on chains (I'm not talking about
> > rules), as I simply cannot find any parsing code for that.
> > 
> > Note that it would make sense only on builtin chains, but not
> > user-chains, because only builtin chains have a policy, and the
> > counters are about packets that hit the policy.
> > 
> > Anyway, it doesn't seem to be restored at all, and I suspect an
> > omission, so... a bug. Can someone confirm?

> Yes, now that you say it, I don't remember having written that code ;)

Did you ask your pet as well? ;-)

> Please put it in bugzilla... and patches are obviously always welcome.

I'm currently writing it, at least partly:
- for now iptables-save (with or without -c) used to dump counters for
  builtin-chains, which is wrong (useless when not called with -c).
  I'll fix that.
- iptables-save (also with or without -c) used to dump dummy counters
  (always [0:0]) for user-chains, which is also wrong (never needed,
  as it makes no sense for user-chains, right?). I'll fix that too.

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). But i think it's acceptable, as:
- people should not want to do that, as they should use
  iptables-restore.new, then
- if people really have to use iptables-restore.old, they can use
  iptables-save.new dumps, but with -c
- a very simple sed line fixes that

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).
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?

Thanks for commenting everything above.

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

  reply	other threads:[~2004-08-20 14:36 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 [this message]
2004-08-20 16:08     ` Herve Eychenne
2004-08-21  0:01     ` Henrik Nordstrom
2004-08-22 20:14       ` Herve Eychenne

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=20040820143617.GD4883@eychenne.org \
    --to=rv@wallfire.org \
    --cc=laforge@netfilter.org \
    --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.