Date: Mon, 22 Mar 1999 11:24:41 +0100 (CET) From: Remy Nonnenmacher <remy@synx.com> To: cc@137.org Cc: julian@whistle.com, freebsd-net@FreeBSD.ORG Subject: Re: Integrating the NetBSD PFIL hooks.. Message-ID: <199903221032.LAA25950@rt2.synx.com> In-Reply-To: <19990321193930.19005C3@friley-185-205.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Mar, Chris Csanady wrote: > >>Chris Csanady wrote: >>> >>> What would it take for us to intergrate NetBSD's PFIL hooks? It is >>> hard to do much work in the current network stack with so much of >>> the mess that currently exists. At the very least, ip_input.c and >>> ip_output.c would be much cleaner with this mechanism. >>> >>> I'm just wondering what needs to be done, and if it is possible. >>> Ipfilter would already support this, but how about ipfw, dummynet, >>> divert and such? Would the authors of the respective code be >>> willing to help out with the necessary changes? >>> >>> Chris Csanady >>> >>> To Unsubscribe: send mail to majordomo@FreeBSD.org >>> with "unsubscribe freebsd-net" in the body of the message >> >>Certainly >>though I haven't looked.. >>It certainly looks like it could use some cleaning.. It's suffering >>from 'evolutionary changes'. >> >>We at whistle have to take a lot of the blame. >>We implemented 'divert' sockets after a suggestion from >>one of the CSRG guys. (forget his name.. the Kieth that was >>not a Bostic) >> >>The divert functionality adds a lot of possibilities but it has its >>tentacles all over the place. The 'fwd' option of ipfw has a few >>tentacles reaching as far as tcp_input. > > Hmm, I didn't realize that divert was so far reaching. The NetBSD > PFIL stuff basically only provides for input and output hooks at > a single point as far as I can see. (in ip_input and ip_output) > It seems like it would be simple to extend the interface to do > both fragments and reassembled packets at the IP layer though. > > What is the minimum in terms of filtering points that must exist? > > Chris All these 'tentacles' comes from the fact that every point of processing of a packet needs to know more about interest that this packet can have to an upper-layer. Even bridging in the sentence : "bridge all packets but forward this connection to this socket" must be able to understand quiet everything, from Mac to pcb in order to route the packet. What about generalizing the whistle's Netgraph to the full stack and building a generic traffic classifier ? (I bothered Luigi about it a few time... Sorry Luigi ;). RN. IaM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903221032.LAA25950>