From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 22:49:18 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 D621A106566B for ; Wed, 30 Dec 2009 22:49:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 996648FC15 for ; Wed, 30 Dec 2009 22:49:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 021FB7310A; Wed, 30 Dec 2009 23:57:06 +0100 (CET) Date: Wed, 30 Dec 2009 23:57:05 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20091230225705.GC64766@onelab2.iet.unipi.it> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B3BC659.7010707@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: Ian Smith , 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 22:49:19 -0000 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 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. > > > >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) E. For the records, packets going through dummynet and reinjected because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE. I think there is some agreement that "tee" and "ngtee" should do the same thing for the original packet (the one that continues processing), and i believe the correct approach is #D (i.e. continue from the NEXT RULE). The point of my original question was to correct what is done in case #B above. I am less clear on what to do for the packets passed to the divert socket or netgraph node (cases #A and #B above), but i would vote for keeping things unchanged because it is the best we can do. (Ideally, I think that all forms of diversion should continue by default from the NEXT RULE -- this is what currently happens with netgraph #B and dummynet #E. But we cannot change "divert" #A because of API limitations, and I think we cannot change dummynet #E to continue with the next numbered rule because it breaks existing configurations. cheers luigi