From owner-freebsd-net@FreeBSD.ORG Wed Jan 19 09:32:44 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 51BAD16A4CE; Wed, 19 Jan 2005 09:32:44 +0000 (GMT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4EA943D55; Wed, 19 Jan 2005 09:32:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j0J9Waxw090080; Wed, 19 Jan 2005 04:32:37 -0500 Message-ID: <41EE2933.4090404@elischer.org> Date: Wed, 19 Jan 2005 01:32:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20050117200610.GA90866@cell.sick.ru> <20050118183558.GA15150@odin.ac.hmc.edu> <41ED8D63.8090205@elischer.org> <20050119084526.GA5119@cell.sick.ru> In-Reply-To: <20050119084526.GA5119@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; 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: Wed, 19 Jan 2005 09:32:44 -0000 Gleb Smirnoff wrote: > On Tue, Jan 18, 2005 at 02:27:47PM -0800, Julian Elischer wrote: > J> firstly.. I was thinking that there are several good ways to mesh the > J> ipfw/divert/netgraph > J> stuff. > J> > J> Firstly there is the possibility of making the ipfw stuff a netgraph > J> node itself.. > > Yes, but this is a separate node. I'm working on a node doing opposite > thing, it will allow to filter netgraph traffic using an arbitrary > ipfw chain. > > J> (yes I know there is such a node (based on ipfw-1) out there.) > > If you are speaking about a node from BWMAN, then it is not based on > ipfw. It uses its own filter engine, AFAIK. > > J> then as for getting stuff out of ipfw, maybe divert itself could be > J> changed to be > J> a netgraph method. In this way, you'd open netgtraph sockets instead of > J> divert sockets. > J> > J> Alternatively there could be a possibility where netgraph could open > J> hooks of a particular number > J> and that would be the equivalant of openning a divert hook of that number.. > J> > J> Looks good but I'm not convinced that it needs a whole new keyword of we > J> tap in through the divert mechanism. > > Divert is a socket, and ng_ipfw is not. We tap thru a direct call to netgraph. > > I think, divert is designed for userland interaction. It is possible to use > it for netgraph (via ng_ksocket), but this adds overhead of passing the socket > layer, and I believe not all bugs are caught in this setup. That's why I prefer > two different keywords, which do completely different things. I'm not sure they do two different things.. Each represents a place to send packets. If each active divert socket number had a pointer to the module to which it was attached then you could divert to either in-kernel netgraph targets or to userland socket based targets. Currently of you divert to a divert 'port number' and nothing is attached to it, the packet is dropped. If a divert socket is attached to it, it is sent ot teh socket. I would just suggest that is not a great leap of imagination that attaching to a hook named 3245 would attach a netgrpah hook to the ipfw code in the sam enamespace as the divert portnumber, and that a subsequent attempt to attach a divert socket to that port number woild fail. The packets diverted there would simply go to the netgraph hook instead of going to a socket or being dropped. >