Date: Tue, 29 Dec 2009 16:45:04 -0800 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" Message-ID: <4B3AA290.8000508@elischer.org> In-Reply-To: <20091230002447.GA55727@onelab2.iet.unipi.it> References: <20091230002447.GA55727@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B3AA290.8000508>