Date: Wed, 30 Dec 2009 01:24:47 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: net@freebsd.org Subject: RFC: documented and actual behaviour of "ipfw tee" Message-ID: <20091230002447.GA55727@onelab2.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
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).
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091230002447.GA55727>