Date: Thu, 31 Dec 2009 18:15:00 +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: <20091231171500.GA82767@onelab2.iet.unipi.it> In-Reply-To: <20091230225705.GC64766@onelab2.iet.unipi.it> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 30, 2009 at 11:57:05PM +0100, Luigi Rizzo wrote:
> On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote:
> > Ian Smith wrote:
> > >On Tue, 29 Dec 2009, Julian Elischer wrote:
> > > > Luigi Rizzo wrote:
> > > > > There a difference between the documented and actual behaviour of
> > > > > "ipfw tee" which occurs when there are multiple rules with the same
> > > > > number, e.g.
> > > > >
> > > > > rule_id number body
> > > > > r1 500 tee port1 dst-ip 1.2.3.0/24
> > > > > r2 500 tee port2 dst-ip 1.2.4.0/24
> > > > > r3 500 accept ip from any to any
> > > > > r4 510 count ip from any to any
> > > > >
> > > > > + the manpage says "processing continues with the NEXT RULE"
> > > > > (so after r1 we have r2, then r3, ...);
> > > > > + the implementation behaves as "processing continues with the
> > > > > NEXT NUMBERED RULE" (ie. after 500 continues with 510).
> > > > >
> > > >
> > > > TEE should go to the next RULE with the original packet, but if
> > > > you reinject the tee'd copy of the packet it should go to the
> > > > next rule NUMBER.
> > >
> > >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.
>
> C. with "netgraph", the packet is passed to the netgraph node,
> and when/if reinjected processing continues with the NEXT RULE.
> This is different from #A
>
> D. with "ngtee", the copy of the packet that goes to the netgraph
> node behaves as in #C. The original packet, continues processing
> with the NEXT RULE (again, different from "tee" processing in #B)
Upon inspection, it seems that ngtee is different from what I said above.
The comment in ng_ipfw_input() says
/*
* We have two modes: in normal mode we add a tag to packet, which is
* important to return packet back to IP stack. In tee mode we make
* a copy of a packet and forward it into netgraph without a tag.
*/
which means that with ngtee, the copy that goes to netgraph is
untagged, so i totally fail to understand what is the expected
usage model.
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091231171500.GA82767>