RFC: documented and actual behaviour of "ipfw tee"
rizzo at iet.unipi.it
Thu Dec 31 17:07:12 UTC 2009
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 126.96.36.199/24
> > > > > r2 500 tee port2 dst-ip 188.8.131.52/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
More information about the freebsd-net