Because fetching a counter is a rather expansive function we should use counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr pass" rule should not cause more effort than separate "rdr" and "pass" rules. For rules with adaptive timeout values the call of counter_u64_fetch() should be accepted, but otherwise not. From the man page: The adaptive timeout values can be defined both globally and for each rule. When used on a per-rule basis, the values relate to the number of states created by the rule, otherwise to the total number of states. This handling of adaptive timeouts is done in pf_state_expires(). The calculation needs three values: start, end and states. 1. Normal rules "pass .." without adaptive setting meaning "start = 0" runs in the else-section and therefore takes "start" and "end" from the global default settings and sets "states" to pf_status.states (= total number of states). 2. Special rules like "pass .. keep state (adaptive.start 500 adaptive.end 1000)" have start != 0, run in the if-section and take "start" and "end" from the rule and set "states" to the number of states created by their rule using counter_u64_fetch(). Thats all ok, but there is a third case without special handling in the above code snippet: 3. All "rdr/nat pass .." statements use together the pf_default_rule. Therefore we have "start != 0" in this case and we run the if-section but we better should run the else-section in this case and do not fetch the counter of the pf_default_rule but take the total number of states. Submitted by: Andreas Longwitz <longwitz@incore.de> MFC after: 2 weeks |
||
---|---|---|
.. | ||
if_pflog.c | ||
if_pfsync.c | ||
in4_cksum.c | ||
pf_altq.h | ||
pf_if.c | ||
pf_ioctl.c | ||
pf_lb.c | ||
pf_mtag.h | ||
pf_norm.c | ||
pf_osfp.c | ||
pf_ruleset.c | ||
pf_table.c | ||
pf.c | ||
pf.h |