From owner-freebsd-net@FreeBSD.ORG Thu Jan 20 21:38:16 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2A2616A4CE; Thu, 20 Jan 2005 21:38:16 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 399CF43D1D; Thu, 20 Jan 2005 21:38:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D12607A403; Thu, 20 Jan 2005 13:38:15 -0800 (PST) Message-ID: <41F024C7.30203@elischer.org> Date: Thu, 20 Jan 2005 13:38:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brooks Davis References: <20050117200610.GA90866@cell.sick.ru> <20050118183558.GA15150@odin.ac.hmc.edu> <41ED8D63.8090205@elischer.org> <20050119084526.GA5119@cell.sick.ru> <41EE2933.4090404@elischer.org> <20050120134553.GB18668@cell.sick.ru> <20050120193432.GB12156@odin.ac.hmc.edu> In-Reply-To: <20050120193432.GB12156@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Jan 2005 21:38:16 -0000 Gleb, as long as you have done enuogh work to evaluate other options (as you have,) I have no objection to you committing your original idea. Brooks Davis wrote: >On Thu, Jan 20, 2005 at 04:45:53PM +0300, Gleb Smirnoff wrote: > > >> Julian, >> >>On Wed, Jan 19, 2005 at 01:32:35AM -0800, Julian Elischer wrote: >>J> I'm not sure they do two different things.. Each represents a place to >>J> send packets. >>J> If each active divert socket number had a pointer to the module to which it >>J> was attached then you could divert to either in-kernel netgraph targets or >>J> to userland socket based targets. Currently of you divert to a divert >>J> 'port number' and nothing is attached to it, the packet is dropped. >>J> If a divert socket is attached to it, it is sent ot teh socket. >>J> I would just suggest that is not a great leap of imagination that >>J> attaching to a hook named 3245 would attach a netgrpah hook to the ipfw >>J> code in the sam enamespace as the divert portnumber, and that a >>J> subsequent attempt to attach a divert socket to that port number woild >>J> fail. The packets diverted there would simply go to the netgraph hook >>J> instead of going to a socket or being dropped. >> >>Well, I've considered this. We are going to have these negatives with this change: >> >>1) require divert loaded/compiled, when we are going to work with a completely >> different thing. >>2) Acquire & drop lock on divert pcb info for each packet going into netgraph. >>3) Extensively hack divert_packet()... Let me explain. The place where we can tell >>whether we have a socket diversion or a netgraph diversion, is at the very end >>of divert_packet(). Before this place many things are done, which does not apply >>to a netgraph diversion. >>This hacking may bring bugs into divert infrastructure, and add extra CPU cycles >>for case of netgraph forwarding. I think saving one keyword for ipfw2 doesn't >>worth this hacks. >> >> > >I think the code should be committed more or less as is. I think the >netgraph and divert features are relatively orthogonal. > >-- Brooks > > >