RFC: documented and actual behaviour of "ipfw tee"

[Julian Elischer]

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.

> The actual behaviour is an artifact of how "divert" is implemented:
> diverted packet only carry the rule number so we cannot tell, on a
> reinject, which of the rules numbered "500" matched, and we restart
> from the next one. Tee was implemented as an extension of divert.
> 
> Skipping rules in my opinion is very unintuitive, but there is
> no way to fix it (unless we extend the API) as the rule_id is only
> known within the kernel.
> 
> For 'tee', however, packets  the situation is different because the
> copy of the packet that remains in the kernel does not lose knowledge
> of the matching rule so we can easily continue from the very next
> rule, same as it happens for dummynet packets with one_pass=0 (and
> tee'd netgraph packets, which I think already do "the right thing").
> 
> Since I am doing some work in this are of the code, I'd like to ask
> opinions on how to proceed:
> 
>     A. preserve the current behaviour and fix the manpage;
>     B. fix the code to behave as the manpage says;
>     C. introduce a sysctl to choose between A and B.
> 	Of course this moves the problem on which default
> 	to choose :)
> 
> Because it is a very special case that I doubt many people have hit,
> I'd be inclined to do B and consider the old behaviour a bug.
> 
> 	cheers
> 	luigi
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"