On Thu, Nov 27, 2003 at 09:52:24AM +0700, Dmitriy Medvedev wrote: > so its normal behaviour or not?
It's intentional behaviour, though I see why you might expect it to behave differently. When you load a new ruleset (or just reload an unchanged ruleset), pf doesn't try to associate the new rules with the old ones. Existing state entries (created by the previous ruleset) will not be reassigned to new rules. This becomes visible when you run pfctl -vss, which shows what rule (number) created each state entry. States created before the most recent reload will not show a rule number. Reversely, pfctl -vsr (which shows the number of existing state entries created from each rule) will show "States: 0" for every rule after loading a ruleset. Consequently, the rule's keep state max limits will not include states created before the rules were loaded. In the special case where you reload an unmodified (or slightly modified) ruleset, it would be possible for pf to 'guess' which new rule is equivalent to which old rule, but even moderate changes in the new ruleset might make that difficult or impossible to do with useful precision. Another approach would be to reassign each existing state entry to a rule in the new ruleset by evaluating the new ruleset (simulating what would happen, with the new ruleset, if the state didn't exist but the initial packet of the connection was seen now). But that's a rather expensive operation, if you have a non-trivial amount of state entries, and would have to be done on each ruleset change. If the man page doesn't mention this, I guess adding a brief sentence wouldn't hurt. Suggestions/diff welcome :) Daniel
