From owner-freebsd-arch Thu Jun 13 17:13:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8DE9D37B400; Thu, 13 Jun 2002 17:13:20 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5E0DKp94630; Thu, 13 Jun 2002 17:13:20 -0700 (PDT) (envelope-from rizzo) Date: Thu, 13 Jun 2002 17:13:19 -0700 From: "'Luigi Rizzo'" To: arch@freebsd.org Subject: ipfw rewrite - new snapshot available Message-ID: <20020613171319.D93980@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Bcc to -net] Hi, as I mentioned in a posting to -net a few days ago, over the past weeks I have done an extensive rewrite of the ipfw code (both userland and kernel) in an attempt to make it faster, more flexible and more manageable. The code is now almost ready for commit, so I would appreciate some feedback if any of you feels like trying it and, even better, run some performance test. You can fetch the code from http://info.iet.unipi.it/~luigi/ipfw5.20020613.tgz This is for a -current after May 15th, and replaces sys/netinet/ip_fw.c sys/netinet/ip_fw.h sys/netinet/ip_dummynet.c sbin/ipfw/ipfw.c The idea behind this work was to replace the old ipfw rules (macroinstructions) with a set of microinstructions, each of them performing a single operation such as matching an address, or a port range, or a protocol flag, etc. -- much in the spirit of BPF and derivatives -- and to let the userland front-end compile ipfw(8) commands into an appropriate set of microinstructions. There are several advantages in using this technique: first of all, instructions are typically shorter and faster, because the old code had to check for the presence of all the possible options (there are over 25 of them!) in a rule, whereas the new one can simply do just the things that are required. I have implemented all the actions (accept/deny/pipe/divert/forward ...) and almost all the 25+ (ouch!) different options that can be specified in a rule. The syntax for the userland program is 100% backward compatible. I have also implemented a few extensions to demonstrate the flexibility of the new approach: you can put "or" connectives between fields, so you can write things like ipfw add allow ip from host1 or host2 or host3 or not net1/24 to any and the like, and this greatly simplifies writing rulesets as you can imagine. Other extensions (in the form of address sets, multiple rule chains to be used on layer-2 and layer-3 firewalls, etc. will be trivial to implement. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message