Date: Thu, 16 Jan 1997 23:10:20 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: proff@suburbia.net Cc: phk@freebsd.org, hackers@freebsd.org Subject: Re: ipfw patches to test Message-ID: <199701161211.EAA18550@freefall.freebsd.org> In-Reply-To: <19970116020616.24911.qmail@suburbia.net> from "proff@suburbia.net" at Jan 16, 97 01:06:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701161211.EAA18550>