RFC: documented and actual behaviour of "ipfw tee"

[Luigi Rizzo]

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