Date: Mon, 14 Jan 2008 13:15:32 +1100 From: Lawrence Stewart <lstewart@freebsd.org> To: Subhash Gopinath <subhashg.unix@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: netgraph question Message-ID: <478AC5C4.7000709@freebsd.org> In-Reply-To: <5db9d2e0801121140x76c26a6k20e12a21db4cf0ae@mail.gmail.com> References: <5db9d2e0801112010s55812b20p6a43f0fbb5cddd17@mail.gmail.com> <47885EF3.8070104@freebsd.org> <5db9d2e0801121140x76c26a6k20e12a21db4cf0ae@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <lstewart@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478AC5C4.7000709>