On Thu, Feb 17, 2005 at 08:51:09PM +0100, Manon Goo wrote:

> pass in on { $adm_if, $adm_carp_if } proto { tcp, udp, icmp } from \
> host01, host02 } to any flags S/SA tag HOSTOUT keep state
> pass in quick tagged HOSTOUT keep state ( max 40 )
>
> pass in on $adm_if proto tcp from host3 to any port 80 flags S/SA \
> keep state (max 40)

Load that ruleset and make sure it is loaded correctly (pfctl -sr). Then
flush all state entries (pfctl -Fs) and establish more than 40
connections. Then run pfctl -vss and identify the >40 state entries.
Compare the rule number printed with each state entry with the output of
pfctl -vvsr.

If you can show more than 40 state entries which all reference a single
rule number, and that rule, printed by pfctl -vvsr, contains the option
'keep state (max 40)', that would be a bug.

If those >40 state entries are created by different rules or by rules
that don't contain 'keep state (max)' options, you'll have the
explanation of why there can be more than 40 states.

The 'keep state (max)' option in a rule only limits the number of states
created by this particular rule. States created by other rules are not
affected. If two or more rules with max limits create states, the limit
of each rule applies individually (that is, the sum of states created by
all these rules can be as high as the sum of all limits). Also, if you
reload the ruleset, existing states created by the former ruleset are
not associated with the new rules' maxima (hence the state flushing in
the instructions above).

Maybe it's just a misunderstanding of what the max limit is doing. Or
you weren't aware of other rules creating state in your case. If you
really suspect a bug, you'll have to provide the output from the
commands mentioned above as proof

Daniel