'prevmatch' patch

[Bill Fumerola]

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 at yahoo-inc.com / billf at FreeBSD.org