From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 00:38:52 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 6EF2F106568B for ; Thu, 31 Dec 2009 00:38:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 53F9A8FC16 for ; Thu, 31 Dec 2009 00:38:52 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A9008B3E6; Wed, 30 Dec 2009 16:39:43 -0800 (PST) X-Client-Authorized: MaGic Cook1e 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 8DE502D6013; Wed, 30 Dec 2009 16:38:51 -0800 (PST) Message-ID: <4B3BF29B.2040607@elischer.org> Date: Wed, 30 Dec 2009 16:38:51 -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> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> <4B3BE85B.6080309@elischer.org> <20091231003616.GA73067@onelab2.iet.unipi.it> In-Reply-To: <20091231003616.GA73067@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 31 Dec 2009 00:38:52 -0000 Luigi Rizzo wrote: > On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote: >> Luigi Rizzo wrote: > ... >>>>> 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. >> This is unexpected. It should continue at the next rule >> are you sure? > > yes. this happens because the original has the same mtag as the > reinjected 'diverted' packet. I can fix it easily now that we > have rule_id. In the past it cold be fixed too, but needed more > restructuring of code. I had code somewhere where tee didn't leave firewall, but just sent the other packet out, so it could just continue on. at Ironport I had to hack on divert/tee a bit to make it work well with L2 packets. so that got rewritten a bit. > >