Re: ipf.conf "age" parameter and kernel timeout values

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 <[email protected]>:
>
> At 17:11:22.28 on 10-AUG-2011 in message <[email protected]=
.au>,
> Darren Reed <[email protected]> wrote:
>
>>On 10/08/2011 8:17 PM, Michael T. Davis wrote:
>>> =A0 =A0 =A0I'm trying to understand what connections there are, if an=
y, 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_*t=
ime*
>>> kernel variables. =A0These 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 =A0 =A0 =A0 min 0x1 max 0x7fffffff =A0current 86400=
0
>>> fr_tcptimeout =A0 min 0x1 max 0x7fffffff =A0current 480
>>> fr_tcptimewait =A0min 0x1 max 0x7fffffff =A0current 480
>>> fr_udptimeout =A0 min 0x1 max 0x7fffffff =A0current 240
>>> fr_udpacktimeout =A0 =A0 =A0 =A0min 0x1 max 0x7fffffff =A0current 24
>>> fr_icmptimeout =A0min 0x1 max 0x7fffffff =A0current 120
>>> fr_icmpacktimeout =A0 =A0 =A0 min 0x1 max 0x7fffffff =A0current 12
>>> fr_iptimeout =A0 =A0min 0x1 max 0x7fffffff =A0current 120
>>>
>>> =A0 =A0 =A0Presumably, there's some form of mapping between these var=
iables and
>>> use of the value(s) for the age parameter that go something like this=
:
>>>
>>> =A0...proto tcp...keep state...age... -> fr_tcp*
>>>
>>> =A0...proto udp...keep state...age... -> fr_udp*
>>>
>>> =A0...proto icmp...keep state...age... -> fr_icmp*
>>>
>>> =A0(any other IP-based packet)...age... -> fr_iptimeout
>>>
>>> (Related to the last item, can IPFilter [v4.1.29, in particular] actu=
ally
>> keep
>>> state for anything other than TCP, UDP, and/or ICMP?) =A0Anyway, I wo=
uld
>>> appreciate it if someone might clarify this and/or correct it if I'm
>> completely
>>> off-base. =A0Also, 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
>>
>
> =A0 =A0 =A0 =A0OK, in general this makes sense. =A0Please note that I s=
pecified all the
> IPF kernel variables that have "time" somewhere in their names, so I do=
n't see
> how the age parameter could affect them all. =A0I believe that age actu=
ally only
> deals with fr_<proto>timeout values, right?
>
> =A0 =A0 =A0 =A0I did a little digging through some old sources and ip_s=
tate.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 =3D FIVE_DAYS,
> =A0/* [...] */
> =A0 =A0 =A0 fr_tcptimeout =3D 2 * TCP_MSL,
> =A0/* [...] */
> =A0 =A0 =A0 fr_udptimeout =3D 240,
> =A0 =A0 =A0 fr_icmptimeout =3D 120;
>
> These values are reflected in the "modern" version of IPF from which th=
e
> above values were cited. =A0If the value is expressed in seconds, why t=
he 2x
> multiplier? =A0Doesn't this really mean FIVE_DAYS actually represents 1=
0 days?
> Or is whatever you're using to track time based on a granularity of 0.5
> seconds? =A0If I use the age parameter, I just want to make sure the va=
lue(s)
> I specify really mean what I think they mean.
>
> Thanks,
> Mike
>