From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 00:45:06 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02388106568B for ; Wed, 30 Dec 2009 00:45:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id DD5A98FC13 for ; Wed, 30 Dec 2009 00:45:05 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7BFF8C482; Tue, 29 Dec 2009 16:45:05 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 258352D6012; Tue, 29 Dec 2009 16:45:05 -0800 (PST) Message-ID: <4B3AA290.8000508@elischer.org> Date: Tue, 29 Dec 2009 16:45:04 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Luigi Rizzo References: <20091230002447.GA55727@onelab2.iet.unipi.it> In-Reply-To: <20091230002447.GA55727@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 00:45:06 -0000 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"