Date: Thu, 31 Dec 2009 01:36:16 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Julian Elischer <julian@elischer.org> Cc: Ian Smith <smithi@nimnet.asn.au>, net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" Message-ID: <20091231003616.GA73067@onelab2.iet.unipi.it> In-Reply-To: <4B3BE85B.6080309@elischer.org> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> <4B3BE85B.6080309@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote: > Luigi Rizzo wrote: ... > >>>Which is what happens now, right? Same behaviour on tee reinjection as > >>>divert does seem consistent. So if there is a problem, it's only with > >>>the original packet continuing with the next rule if same-numbered? > >>from Luigi's description I'm not sure what happens now.. :-) > > > >fair enough, let me explain again: > >A. with "divert" the packet is passed to the divert > > socket, and when/if reinjected processing continues no earlier > > than the the NEXT NUMBERED rule. This is a restriction due to the > > current divert socket API that I have no intention to change. > > > >B. with "tee", the copy of the packet that goes to the socket > > behaves the same as above. The original, which remains in > > the kernel, continues processing from the NEXT NUMBERED RULE. > > This is unexpected. It should continue at the next rule > are you sure? yes. this happens because the original has the same mtag as the reinjected 'diverted' packet. I can fix it easily now that we have rule_id. In the past it cold be fixed too, but needed more restructuring of code. ... > > > >E. For the records, packets going through dummynet and reinjected > > because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE. > > what if someone rewrites the firewall while they are 'away'? this is dealt as an exception, in different ways: - In RELENG-7, the mtag contains a pointer to the continuation rule. If the firewall is modified (with an ipfw delete) all pointers are cleared and the packet goes to the default rule. BTW i think packets in netgraph nodes are not protected by this and we might dereference an invalid pointer. - in RELENG_8, with the rule_id feature, we track exactly the matching rule, so if that rule is still existing we can locate it, and continue from the next one (at the time of the reinjection). If the original matching rule disappears, then we jump to the default rule; - in HEAD, with the recent changes i made, rule identifiers are ordered (rulenum:rule_id) so even if the original matching rule disappears i can still locate the next one, and dont need to use the default rule. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091231003616.GA73067>