[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: ipf.conf "age" parameter and kernel timeout values
From:       Saša Nedvědický <anedvedicky () gmail ! com>
Date:       2011-08-11 6:59:28
Message-ID: 22872_1313046447_4E437FAF_22872_1280_2_CA+fgqEC5_ZMuh4SaRT3XXGf=80UWMctYgMuzM63mahTon-SQvA () mail ! gmail ! com
[Download RAW message or body]

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 <DAVISM@ecr6.ohio-state.edu>:
>
> At 17:11:22.28 on 10-AUG-2011 in message <4E43037D.30603@reed.wattle.id.au>,
> Darren Reed <darrenr@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
>

[prev in list] [next in list] [prev in thread] [next in thread]