From owner-freebsd-hackers Sat Feb 19 4: 1:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 8C99A37BBEE for ; Sat, 19 Feb 2000 04:01:07 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id XAA01927; Sat, 19 Feb 2000 23:01:26 +1100 (EST) From: Darren Reed Message-Id: <200002191201.XAA01927@cairo.anu.edu.au> Subject: Re: post 4.0...adoption of pfil(9) from NetBSD ? To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Sat, 19 Feb 2000 23:01:26 +1100 (Australia/NSW) Cc: hackers@FreeBSD.ORG In-Reply-To: <200002191046.LAA84458@info.iet.unipi.it> from "Luigi Rizzo" at Feb 19, 2000 11:46:41 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In some mail from Luigi Rizzo, sie said: > > > I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6, > > to see what's required for IP-Filter (hoping for a clean interface) > > and the response is "sigh". The old ipfw mechanism needs to be > > abandoned, IMHO. > > can you comment a bit more ? I am a bit unclear on what > exactly is thay you don't find appropriate in ipfw etc. The problem is that the in kernel support for ipfw/ipfilter is *specific* to each. There is no mechanism for 3rd party people to add their own without making the same ugly hacks as already exists unless they choose to use the ipfw/ipfilter hook instead. i.e. each time we want to filter a new protocol we need to hack the various functions for a filter specific hook rather than using a generic filter/calling mechanism. > If you have an URL for a pfil(9) manpage i would appreciate it. See below for man page from 1.4. > Some comments: > > The issue of one vs. multiple lists (per direction, interface, > protocol, you name it) has been discussed some time ago. For sure > multiple lists are a (minor, given that we can start the ipfw lists > with a few of "skipto") performance improvement over a single one, > at the possible price of having some duplication in writing filters > and even defining how many lists are appropriate. To me, this outlines how bad the current system for ipfw support has become. Need something ? Just hack the appropriate part of the kernel. There's no real design in the infrastructure for ipfw. Sort of what Linux was like before they redesigned their firewalling, etc, interfaces using netfilter. I must point out that whilst pfil(9) as found in NetBSD does not provide enough support for the various FreeBSDisms to be put in as it is, I think it can be expanded upon, whilst still supporting the same interface, to meet FreeBSD's needs. Darren PFIL(9) NetBSD Kernel Manual PFIL(9) NAME pfil, pfil_hook_get, pfil_add_hook, pfil_remove_hook - packet filter in- terface SYNOPSIS #include #include #include #include struct packet_filter_hook * pfil_hook_get(int); void pfil_add_hook(int (*func)(), int flags); void pfil_remove_hook(int (*func)(), int flags); DESCRIPTION The pfil interface allows a function to be called on every incoming or outgoing packets. The hooks for these are embedded in the ip_input() and ip_output() routines. The pfil_hook_get() function returns the first member of a particular hook, either the in or out list. The pfil_add_hook() function takes a function of the form below as it's first argument, and the flags for which lists to add the function to. The pos- sible values for these flags are some combination of PFIL_IN and PFIL_OUT. The pfil_remove_hook() removes a hook from the specified lists. The func argument is a function with the following prototype. func(void *data, int hlen, struct ifnet *net, int dir, struct mbuf **m) The data describes the packet. Currently, this may only be a pointer to a ip structure. The net and m arguments describe the network interface and the mbuf holding data for this packet. The dir is the direction; 0 for incoming packets and 1 for outgoing packets. if the function returns non-zero, this signals an error and no further processing of this packet is performed. The function should set errno to indicate the nature of the error. It is the hook's responsibiliy to free the chain if the pack- et is being dropped. The pfil interface is enabled in the kernel via the PFIL_HOOKS option. RETURN VALUES If successful pfil_hook_get() returns the first member of the packet fil- ter list, pfil_add_hook() and pfil_remove_hook() are expected to always succeed. HISTORY The pfil interface first appeared in NetBSD 1.3. The pfil input and out- put lists were originally implemented as LIST structures; however this was changed in NetBSD 1.4 to TAILQ struc- tures. This change was to allow the input and output filters to be pro- cessed in reverse order, to allow the same path to be taken, in or out of the kernel. BUGS The current pfil implementation will need changes to suit a threaded ker- nel model. SEE ALSO bpf(4) NetBSD 1.4 August 4, 1996 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message