Just had a quick look, try this patch (not extensively tested and
relative to a modified 4.1.9 tree).
You might also want to change tools/ipfstat.c and remove the duplicate
maximum/no memory entry.
Regards,
Frank
--- ip_state.c.orig Wed Nov 30 21:36:23 2005
+++ ip_state.c Wed Nov 30 21:37:14 2005
@@ -2786,6 +2786,11 @@
if (ipstate_logging != 0 && why != 0)
ipstate_log(is, why);
+ if (is->is_p == IPPROTO_TCP)
+ ips_stats.iss_fin++;
+ else
+ ips_stats.iss_expire++;
+
if (is->is_rule != NULL) {
is->is_rule->fr_statecnt--;
(void)fr_derefrule(&is->is_rule);
@@ -2911,10 +2916,6 @@
}
if (delete) {
- if (is->is_p == IPPROTO_TCP)
- ips_stats.iss_fin++;
- else
- ips_stats.iss_expire++;
fr_delstate(is, ISL_FLUSH);
removed++;
} else
Corey Johnston wrote:
I'm not sure if this is a bug or a feature, but IPF v4 doesn't seem to
record expired/closed connections as v3 did.
That is, in v4 the "expired" and "closed" connections (as reported with
ipfstat -s) remain at 0, even when the number of active connections
decreases.
In version 3, both the "expired" and "closed" counters increased as
active connections decreased.
I'm comparing IPF 3.4.29 (NetBSD) to IPF 4.1.8 (Solaris10), and its
quite clear that the counters don't seem to work in the same way.
I can't find any documentation explaining this, and am wondering if its
a bug in the 4.x series that the closed/expired counters remain stuck at 0.
I've also tested version 4 under NetBSD 2.0 and it seems to function the
same as in Solaris 10, so I'm assuming its not a platform-specific bug.
**Some output below from a production firewall (3.4.29) and a test
firewall (4.1.8) highlights the problem.
$ sudo ipfstat -s
IP states added:
22289866 TCP
236176 UDP
38601 ICMP
2140574757 hits
146274033 misses
0 maximum
0 no memory
6084 bkts in use
6865 active
274774 expired (NB: Non-zero)
22283004 closed (NB: Non-zero)
$sudo ipfstat -s
IP states added:
1126 TCP
0 UDP
0 ICMP
28118 hits
14929 misses
0 maximum
0 no memory
0 max bucket
0 maximum
0 no memory
1097 bkts in use
1118 active
0 expired (NB: zero)
0 closed (NB: zero)
State logging enabled
NB: Exactly the same ruleset is applied to both firewalls, and its clear
that the v3 firewall correctly updates the closed/expired connections,
whereas in v4, they remain stuck at 0.
As this firewall is to be moved into a relatively high-load webserver
environment, I'm reluctant to install it with discrepancies in the
figures reported.
Is this just a bug in the statistics, or is it indicative of a state
table leak?
Any suggestions would be welcomed!
--
Corey Johnston
