From owner-freebsd-current Wed Jan 15 19:48:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA24657 for current-outgoing; Wed, 15 Jan 1997 19:48:15 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA24651 for ; Wed, 15 Jan 1997 19:48:10 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.3/8.7.3) with SMTP id WAA11638; Wed, 15 Jan 1997 22:46:15 -0500 (EST) Message-Id: <199701160346.WAA11638@whizzo.transsys.com> X-Mailer: exmh version 2.0alpha 12/3/96 To: Poul-Henning Kamp cc: Joe Greco , ejs@bfd.com (Eric J. Schwertfeger), nate@mt.sri.com, current@freebsd.org From: "Louis A. Mamakos" Subject: Re: ipfw cannot do this... References: <28389.853360616@critter.dk.tfs.com> In-reply-to: Your message of "Wed, 15 Jan 1997 21:36:56 +0100." <28389.853360616@critter.dk.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Jan 1997 22:46:15 -0500 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is the point where a firewall module using the bpf engine becomes > interesting, and the task more or less changes to one of compiler- > writing... I've done this in a user-mode SLIP implementation on another processor, and it's quite handy and too difficult to do. It turns out that the "compiler" already exists - you can fairly easily extract the one in tcpdump(1) and bend it to your will. Once you've done this in a general purpose way, you could put it in into a dial-on-demand PPP implemenatation have very fine-grained control over what sort of packets are allowed to bring an on-demand PPP link up, and what sort of packets will serve to keep the link from timing out due to inactivity. louie