Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 May 2004 02:42:06 -0700
From:      Luigi Rizzo <rizzo@icir.org>
To:        Oleg Bulyzhin <oleg@rinet.ru>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: ipfw: ouch!, skip past end of rules, denying packet
Message-ID:  <20040507024206.B61144@xorpc.icir.org>
In-Reply-To: <20040507111750.Q3806@lath.rinet.ru>; from oleg@rinet.ru on Fri, May 07, 2004 at 01:17:22PM +0400
References:  <104341060709.20040505171307@vkt.lt> <20040505194451.V9766@lath.rinet.ru> <20040507013009.H1824@lath.rinet.ru> <20040506153815.A75812@xorpc.icir.org> <20040507111750.Q3806@lath.rinet.ru>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Fri, May 07, 2004 at 01:17:22PM +0400, Oleg Bulyzhin wrote:
...
> > Your patch replaces the matching rule with the next one,
> > which however might still end up being the default rule;
> > so it does not fix the proble, plus, it might completely
> > subvert the packet's flow.
> 
> I've used dn_pkt.rule cause dn_pkt structure has no separate pointer for
> 'next rule', perhaps we should add it?

the problem is that there is a race here -- you start processing
the packet, suspend, change the ruleset, then if one_pass=0 restart.
When you restart,
the ruleset might have little or nothing in common with the previous
one, so there isn't really any assumption you can make that doesn't
open holes in your firewall.
So i really believe the only sensible choice in the above case
is either drop the packet, or restart its processing from the
beginning (but that might have annoying side effects).

Dropping a packet (or a few) during a reconfiguration is not dramatic,
it might have got lost anyways -- and note, this case is very
different from reconfiguring a pipe's bandwidth, where you _know_
what to do with the packet (and still you cannot guarantee
if it will come out at the desired rate).

	cheers
	luigii



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20040507024206.B61144>