RFC: documented and actual behaviour of "ipfw tee"

[Luigi Rizzo]

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)

E. For the records, packets going through dummynet and reinjected
   because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE.

I think there is some agreement that "tee" and "ngtee" should do
the same thing for the original packet (the one that continues
processing), and i believe the correct approach is #D (i.e. continue
from the NEXT RULE). The point of my original question was to correct
what is done in case #B above.

I am less clear on what to do for the packets passed to the divert
socket or netgraph node (cases #A and #B above), but i would vote
for keeping things unchanged because it is the best we can do.
(Ideally, I think that all forms of
diversion should continue by default from the NEXT RULE -- this is
what currently happens with netgraph #B and dummynet #E.
But we cannot change "divert" #A because of API limitations,
and I think we cannot change dummynet #E to continue with the next
numbered rule because it breaks existing configurations.

	cheers
	luigi