On Tue, Aug 09, 2011 at 22:24 +0200, Alexander Bluhm wrote: > Consider these two rules: > > pass quick 'special match condition' 'do something' keep state > pass quick 'more general match condition' 'do something else' > > With your change, the special packets, matching both rules, would > match the first rule only as long as there are free states left. > After that, they would starting to match the second rule and do > something else. > > Did I get that right? >
Yes > If so, that is not be the behaviour I would expect. It is against > the last match (or first match with quick) semantics we normaly > have. > I'd argue about that. Think of "max 1" as a filtering condition. Then it doesn't match the rule, so it's stated in the man page btw: "When this limit is reached, further packets that would create state will not match this rule until existing states time out." And in fact I'd expect it to work this way. If there was no such rule in the first place we would have to evaluate the whole ruleset. This is not the same as "block in quick". I wonder how deep this mistake made its way into users' rulesets... > If there is a matching rule, use this one. If there is an error > while creating the state, drop the packet. > > bluhm
