From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 14 06:20:33 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE41616A418 for ; Mon, 14 Jan 2008 06:20:33 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.224]) by mx1.freebsd.org (Postfix) with ESMTP id 553C113C43E for ; Mon, 14 Jan 2008 06:20:32 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from [136.186.229.95] (lstewart.caia.swin.edu.au [136.186.229.95]) by swin.edu.au (8.13.6.20060614/8.13.1) with ESMTP id m0E2FWOC016555; Mon, 14 Jan 2008 13:15:32 +1100 Message-ID: <478AC5C4.7000709@freebsd.org> Date: Mon, 14 Jan 2008 13:15:32 +1100 From: Lawrence Stewart User-Agent: Thunderbird 1.5.0.9 (X11/20070123) MIME-Version: 1.0 To: Subhash Gopinath References: <5db9d2e0801112010s55812b20p6a43f0fbb5cddd17@mail.gmail.com> <47885EF3.8070104@freebsd.org> <5db9d2e0801121140x76c26a6k20e12a21db4cf0ae@mail.gmail.com> In-Reply-To: <5db9d2e0801121140x76c26a6k20e12a21db4cf0ae@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on gpo4.cc.swin.edu.au Cc: freebsd-hackers@freebsd.org Subject: Re: netgraph question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 06:20:33 -0000 Subhash Gopinath wrote: > Thanks, looks interesting. > But I was looking at processing the packets in userspace. Sorry I > didn't mention it clearly. Ah ok. I didn't get that from your initial email. Have you looked at the firewall (ipfw and/or pf) code at all? I believe you can use mechanisms like divert sockets (man 4 divert) to pass packets up from the kernel to userspace for processing, and then reinject the packets into the stack if they pass whatever criteria is required. I'm sure there are other mechanisms for getting packets up into userspace as well, but firewall code is probably a good place to start looking for ideas. > > Thanks, > -Subhash > > On Jan 11, 2008 10:32 PM, Lawrence Stewart wrote: >> Hi Subhash, >> >> Subhash Gopinath wrote: >>> Hello folks, >>> >>> I am looking at writing an application program to tap certain ipv6 packets >>> (say icmpv6) >>> using netgraph. The application has to do some processing, before kernel can >>> proceed >>> with those packets. >>> >>> I have vaguely understood netgraph, and I see that I need a ng_socket node >>> in the application, an ng_bpf node, and an ng_ether or ng_iface node in the >>> kernel. >>> >>> My question is. would I need to create such nodes for each interface. Then >>> it becomes unscalable.. >>> Can I have just one socket, bpf, iface node that can tap icmpv6 packets on >>> all interfaces? >> The PFIL(9) interface might also be of interest to you. If all you need >> to do is packet interception and then allow/deny packets based on the >> results of some processing, PFIL might be the way to go. We wrote some >> code (SIFTR [1]) which uses PFIL in a similar capacity and you may want >> to refer to it as an example. >> >> Cheers, >> Lawrence >> >> [1] http://caia.swin.edu.au/urp/newtcp/tools.html >> Cheers, Lawrence