Date: Tue, 27 Jan 2004 02:05:33 -0800 From: Bill Fumerola <billf@FreeBSD.org> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-ipfw@freebsd.org Subject: Re: 'prevmatch' patch Message-ID: <20040127100533.GS40147@elvis.mu.org> In-Reply-To: <20040127010224.B11002@xorpc.icir.org> References: <20040127022307.GP40147@elvis.mu.org> <20040127010224.B11002@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 27, 2004 at 01:02:24AM -0800, Luigi Rizzo wrote: > i cannot make much sense of this. Can you make an actual example ? it allows for fallthrough/!fallthrough behavior. i had multiple skiptos (address based) pointing at a rule (port based) living in a larger block and i didn't want to retest those address conditions. it's more for the mail archives in case someone finds it useful and not really commitworthy. > It seems to me that the only thing 'prevmatch' tells you is > whether or not you got to a rule as a result of a 'count' or 'skipto' > action, which is a special case of a more general (and equally > simple to implement) mechanism that i am planning to add (and i > believe i posted this already some time ago): > > + add to all non-terminal actions (count, skipto, tee) two bitmasks > that specify sets of flags to set and clear, respectively; > + add a new opcode that matches arbitrary bit patterns; > + flags will be preserved in dummynet so they will be accessible > when the packet comes out of a pipe. > > So you will be able to write > > 100 count set 0x10 src-ip 1.2.3.4,5.6.7.8,9.10.11.12 // good guys > 100 count set 0x20 dst-port 80 > 110 count set 0x40 src-ip 10.0.0.0/8,192.168.0.0/16 // bad guys > ... > 500 pipe 1 flags & 0x60 == 0x20 > 500 deny flags & 0x40 != 0 > > and so on. I am still a bit uncertain on the syntax for the 'flags' > opcode -- this is basically the only think stopping me from implementing > the thing. If you want to give it a shot... yeah, someone on a mailing list mentioned this work and i started working something similar for my own amusement. i added more primatives (most of the C equality and assignment operators) but stopped at the userland part. supporting one operator and value is easy, doing multiple operators makes things a bit trickier. the syntax for multiple operators in the 'check' section seems easier to make unambigious than multiple operators in the 'set' section. creating/coding the grammar is harder than the kernel support.. it'd probably be best to commit something like the above and then expand on the language if needed. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127100533.GS40147>