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 %2B0400 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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040507024206.B61144>