From owner-freebsd-net  Mon Mar 22  2:27:48 1999
Delivered-To: freebsd-net@freebsd.org
Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239])
	by hub.freebsd.org (Postfix) with ESMTP id 3E0DE14BD3
	for <freebsd-net@FreeBSD.ORG>; Mon, 22 Mar 1999 02:26:30 -0800 (PST)
	(envelope-from root@synx.com)
Received: from synx.com (rn.synx.com [192.1.1.241])
	by rt2.synx.com (8.9.1/8.9.1) with ESMTP id LAA25950;
	Mon, 22 Mar 1999 11:32:59 +0100 (CET)
Message-Id: <199903221032.LAA25950@rt2.synx.com>
Date: Mon, 22 Mar 1999 11:24:41 +0100 (CET)
From: Remy Nonnenmacher <remy@synx.com>
Reply-To: remy@synx.com
Subject: Re: Integrating the NetBSD PFIL hooks.. 
To: cc@137.org
Cc: julian@whistle.com, freebsd-net@FreeBSD.ORG
In-Reply-To: <19990321193930.19005C3@friley-185-205.res.iastate.edu>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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