Hi, > Or is whatever you're using to track time based on a granularity of 0.5 > seconds? yes, that's correct, all timeout values are defined in number of ticks. and there are 2 ticks in 1 second.
regards sasha 2011/8/11 Michael T. Davis <dav...@ecr6.ohio-state.edu>: > > At 17:11:22.28 on 10-AUG-2011 in message <4e43037d.30...@reed.wattle.id.au>, > Darren Reed <darr...@reed.wattle.id.au> wrote: > >>On 10/08/2011 8:17 PM, Michael T. Davis wrote: >>> I'm trying to understand what connections there are, if any, between >>> the values you can set for the age parameter on ipf.conf rules you're using >> to >>> keep state (i.e. "... age fwd-secs[/rev-secs]") and the various fr_*time* >>> kernel variables. These are the values of the IPF kernel variables on my >>> "stock" NetBSD 5.1 (release) i386 system, per `ipf -T list|grep time'... >>> >>> fr_tcpidletimeout min 0x1 max 0x7fffffff current 864000 >>> fr_tcptimeout min 0x1 max 0x7fffffff current 480 >>> fr_tcptimewait min 0x1 max 0x7fffffff current 480 >>> fr_udptimeout min 0x1 max 0x7fffffff current 240 >>> fr_udpacktimeout min 0x1 max 0x7fffffff current 24 >>> fr_icmptimeout min 0x1 max 0x7fffffff current 120 >>> fr_icmpacktimeout min 0x1 max 0x7fffffff current 12 >>> fr_iptimeout min 0x1 max 0x7fffffff current 120 >>> >>> Presumably, there's some form of mapping between these variables and >>> use of the value(s) for the age parameter that go something like this: >>> >>> ...proto tcp...keep state...age... -> fr_tcp* >>> >>> ...proto udp...keep state...age... -> fr_udp* >>> >>> ...proto icmp...keep state...age... -> fr_icmp* >>> >>> (any other IP-based packet)...age... -> fr_iptimeout >>> >>> (Related to the last item, can IPFilter [v4.1.29, in particular] actually >> keep >>> state for anything other than TCP, UDP, and/or ICMP?) Anyway, I would >>> appreciate it if someone might clarify this and/or correct it if I'm >> completely >>> off-base. Also, are all these values expressed in terms of seconds? >> >>The value that you use in the rule will replace those from above with a >> matching name, as you've rightly guessed. >> >>Darren >> > > OK, in general this makes sense. Please note that I specified all the > IPF kernel variables that have "time" somewhere in their names, so I don't see > how the age parameter could affect them all. I believe that age actually only > deals with fr_<proto>timeout values, right? > > I did a little digging through some old sources and ip_state.c often > used a given base value and then multiplied by two: > > #define FIVE_DAYS (2 * 5 * 86400) /* 5 days: half closed connection */ > > #define TCP_MSL 240 /* 2 minutes */ > > u_long fr_tcpidletimeout = FIVE_DAYS, > /* [...] */ > fr_tcptimeout = 2 * TCP_MSL, > /* [...] */ > fr_udptimeout = 240, > fr_icmptimeout = 120; > > These values are reflected in the "modern" version of IPF from which the > above values were cited. If the value is expressed in seconds, why the 2x > multiplier? Doesn't this really mean FIVE_DAYS actually represents 10 days? > Or is whatever you're using to track time based on a granularity of 0.5 > seconds? If I use the age parameter, I just want to make sure the value(s) > I specify really mean what I think they mean. > > Thanks, > Mike >
