From owner-freebsd-hackers  Thu Jan 16 04:11:34 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA18563
          for hackers-outgoing; Thu, 16 Jan 1997 04:11:34 -0800 (PST)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA18550;
          Thu, 16 Jan 1997 04:11:30 -0800 (PST)
Message-Id: <199701161211.EAA18550@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA157006620; Thu, 16 Jan 1997 23:10:20 +1100
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: ipfw patches to test
To: proff@suburbia.net
Date: Thu, 16 Jan 1997 23:10:20 +1100 (EDT)
Cc: phk@freebsd.org, hackers@freebsd.org
In-Reply-To: <19970116020616.24911.qmail@suburbia.net> from "proff@suburbia.net" at Jan 16, 97 01:06:16 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from proff@suburbia.net, sie said:
> 
> > 
> > Well, I needed this badly, so I looked at it, if somebody wants to
> > try out this little patch, please report how it goes.
> > 
> > Basically you can now say
> > 
> > 	ipfw add deny !from 192.168.23.0/30 to 140.145.230.0/24
> > 
> > or "!to" for that matter.  Give it a whirl...
> > 
> > Poul-Henning
> 
> This is a good addition. When I was playing with the code I was
> quite puzzeled about the lack of this negative logic.

Doesn't work with fast masking based matching (I've often thought of it
and that's why I've never done it - but maybe that means I've never thought
about it in the right way ;).

To give you some idea of what I mean by this, when matching a packet
through IP Filter, it does some preprocessing of the IP header(s) and
matches src, dst, IP options (including security), ttl, tos, version,
protocol, fragmented/not in 5 32bit mask-matches.  If you look at IP
Filter now, you'll notice that it does all 5 of these without branching
(whether it should or shouldn't branch early is dependant on CPU,
especially instruction pipeline depth).

btw, with the rmon fast packet matching with masks reference, were you
alluding to the paper for one of the OSDI(?) conferences where they had
benchmarked it at twice the speed of BPF ?

Darren