From owner-freebsd-net Mon May 1 19:18:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2639037B82B for ; Mon, 1 May 2000 19:18:43 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id WAA18436; Mon, 1 May 2000 22:18:35 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 1 May 2000 22:18:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: ether matching in ipfw?? In-Reply-To: <200005011926.MAA93100@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 1 May 2000, Archie Cobbs wrote: > In trying to clean up this bridging stuff, I just realized that > ip_fw_chk() contains code for matching Ethernet headers and > non IP packets! > > Does the "ip" in "ipfw" not mean anything to anyone?? The BRIDGE/IPFW patch I emailed out earlier removes this bogosity, and has a switch statement where one might consider adding calls to other filtering code. That said, I think this all continues to point to a more generalized structure for inserting filters into packet processing. This again raised the opportunity to plug the BSD/OS code that uses BPF to filter (and even modify) packets, allowing it to behave quite flexibly. You could imagine ng_bpfw filters being inserted strategically in the netgraph module graph and filtering as needed and appropriate. I second Luigi's sentiment that we avoid having too many brands of filtering independently implemented, but suspect that means we need to look beyond ipfw in other ways also. One advantage to a BPF-like approach would be that you could imagine a BPF->native code compiler, instead of a BPF execution vm in kernel, giving performance close to ipfw, if not better, when optimized. These custom filtering modules built from userland rulesets could also be inserted into the graph as needed. Would also be nice to see the BRIDGE functionality as a node sitting above a set of ng_ether nodes. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message