target for modifying conntrack timeout value

target for modifying conntrack timeout value

[Richard]

Hi,

I wonder if there is a target to modify the conntrack timeout value. For
example, an established udp connection has a 180 seconds timeout value. It
is sufficient for most applications. However some need to have a higher
value. What I'd like is the ability to set the timeout value in the
conntrack.

Is there such a target already? If not, is it feasible?

Thanks,
Richard

Re: target for modifying conntrack timeout value

[Kiran Kumar Immidi]

On Wednesday 01 December 2004 06:16, Richard wrote:

> I wonder if there is a target to modify the conntrack timeout value. For

  Its not a target, you just need to set it using sysctl;

sysctl -w net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=<timeout>
-- 
Regards,
Kiran Kumar Immidi

RE: target for modifying conntrack timeout value

[Richard]

This would change the timeout value for all udp conntrack. I'd like to have
more granular control, e.g. after match of certain ports or other
conditions.

Thanks,
Richard


> -----Original Message-----
> From: Kiran Kumar Immidi [mailto:immidi@spymac.com]
> Sent: Tuesday, November 30, 2004 5:51 PM
> To: Richard; netfilter-devel@lists.netfilter.org
> Subject: Re: target for modifying conntrack timeout value
> 
> On Wednesday 01 December 2004 06:16, Richard wrote:
> 
> > I wonder if there is a target to modify the conntrack timeout value. For
> 
>   Its not a target, you just need to set it using sysctl;
> 
> sysctl -w net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=<timeout>
> --
> Regards,
> Kiran Kumar Immidi

Re: target for modifying conntrack timeout value

[Patrick Schaaf]

Hello Richard,

> This would change the timeout value for all udp conntrack. I'd like to have
> more granular control, e.g. after match of certain ports or other
> conditions.

This does not exist, yet, for all I know.

It would require a new data field for each conntrack, "override_timeout".

And then, there would be the interesting question of what to do for
state changes. UDP is easy, but TCP has a load of states it goes
through when the session comes down. Each state transition is coupled
to a per-new-state timeout value. Now, if you give a specific override_timeout,
what to do with it when the next state transition occurs?

Finally, why do you think you need that? What is so special about your
setup that, after one UDP conntrack times out, the next packet for the
same pair of addresses cannot just create a new, equivalent conntrack?
That would be normal operation - what is different for you?

best regards
  Patrick

RE: target for modifying conntrack timeout value

[Richard]

Hi Patrick,

I would expect that the new target will just modify the time left for the
connection. One can 'match' state to see the conditions to change it. So it
is up to the user to decide what value to use for a certain state.

My specific application is for SIP. SIP sends out REGISTER messages to the
outside server. The server would send any call to the inside client via its
NAT address. If the conntrack is no longer there, the inside client can't
receive any SIP message and won't get any call. It needs to keep the
conntrack active far larger than the 3 minutes default.

I am thinking to use "ip_ct_refresh" to change the current value of
conntrack. If it is feasible, the module shouldn't be too hard to write.

Thanks,
Richard

> -----Original Message-----
> From: Patrick Schaaf [mailto:bof@bof.de]
> Sent: Tuesday, November 30, 2004 9:00 PM
> To: Richard
> Cc: 'Kiran Kumar Immidi'; netfilter-devel@lists.netfilter.org
> Subject: Re: target for modifying conntrack timeout value
> 
> Hello Richard,
> 
> > This would change the timeout value for all udp conntrack. I'd like to
> have
> > more granular control, e.g. after match of certain ports or other
> > conditions.
> 
> This does not exist, yet, for all I know.
> 
> It would require a new data field for each conntrack, "override_timeout".
> 
> And then, there would be the interesting question of what to do for
> state changes. UDP is easy, but TCP has a load of states it goes
> through when the session comes down. Each state transition is coupled
> to a per-new-state timeout value. Now, if you give a specific
> override_timeout,
> what to do with it when the next state transition occurs?
> 
> Finally, why do you think you need that? What is so special about your
> setup that, after one UDP conntrack times out, the next packet for the
> same pair of addresses cannot just create a new, equivalent conntrack?
> That would be normal operation - what is different for you?
> 
> best regards
>   Patrick

Re: target for modifying conntrack timeout value

[Patrick Schaaf]

Hi Richard,

> I am thinking to use "ip_ct_refresh" to change the current value of
> conntrack. If it is feasible, the module shouldn't be too hard to write.

conntrack timeouts are set anew for each packet of the connection,
on input, as far as I can tell. Your calling ip_ct_refresh will at
most apply until the next packet of the connection comes by.

> My specific application is for SIP. SIP sends out REGISTER messages to the
> outside server. The server would send any call to the inside client via its
> NAT address. If the conntrack is no longer there, the inside client can't
> receive any SIP message and won't get any call. It needs to keep the
> conntrack active far larger than the 3 minutes default.

Ah. So you would want packet from client->server extend the timeout
to say six hours, so that the eventual incoming call signalling
server->client finds its way to the (hopefully not shut down or
rebooted) SIP end device behind the NAT box.

That should indeed work by calling ip_ct_refresh (ip_ct_refresh_acct
in 2.6, it seems) in e.g. filter, matching --dport 5060. Just make
sure you do it in front of any '-m state --state ESTABLISHED -j ACCEPT'
rules.

Go ahead, write such a target.

best regards
  Patrick

(btw, could you please not top-post?)

RE: target for modifying conntrack timeout value

[Richard]

> That should indeed work by calling ip_ct_refresh (ip_ct_refresh_acct
> in 2.6, it seems) in e.g. filter, matching --dport 5060. Just make
> sure you do it in front of any '-m state --state ESTABLISHED -j ACCEPT'
> rules.
> 
> Go ahead, write such a target.
> 

I finished the code and testing. It is based on the stable versions of
iptables and pom. I'd like to have it included in cvs. Should I post the
patch based on stable or cvs?

Btw, the cvs server seems down now. I followed the instruction in
http://www.netfilter.org/downloads.html#cvs.

Thanks,
Richard

RE: target for modifying conntrack timeout value

[Henrik Nordstrom]

On Sun, 5 Dec 2004, Richard wrote:

> I finished the code and testing. It is based on the stable versions of
> iptables and pom. I'd like to have it included in cvs. Should I post the
> patch based on stable or cvs?
>
> Btw, the cvs server seems down now. I followed the instruction in
> http://www.netfilter.org/downloads.html#cvs.

netfilter moved to subversion some time ago. See announce in the list 
archives.

It appears the web pages have not been updated yet with the new 
information on how to access the subversion repository.

Who is responsible for maintaining the web?

Regards
Henrik

RE: target for modifying conntrack timeout value

[Richard]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

> netfilter moved to subversion some time ago. See announce in the list
> archives.
> 
> It appears the web pages have not been updated yet with the new
> information on how to access the subversion repository.
> 

Ok, I got the latest svn. However I have trouble to get a diff between it
and my working copy. "svn diff" only diffs the existing files and does
generate a patch for new files.

Anyway, I attached this tar.gz file which is extracted into netfilter
directory. Then run "patch -p0 Makefile.diff".

I don't write a 'match' for expire timers because it is already available
through 'match conntrack' with ctexpire option.

It is only available for kernel 2.4, at least for now.

Regards,
Richard

=========================
The related man page part is,

   CTEXPIRE
       This is used to modify the conntrack expire field.  The conntrack
expire field determines how much time left (in seconds) for the conntrack.
The conntrack will  be  deleted  or changed to a new state when the expire
field reachs 0.

       --ctexpire-set value
              Set the conntrack expire value to `value' (in seconds).

       --ctexpire-dec value
              Decrement  the  conntrack  expire  value  `value'  (in
seconds), i.e. make it live shorter.

       --ctexpire-inc value
              Increment the conntrack expire value `value' (in seconds),
i.e. make it live longer.

========================
The help of iptables is,

CTEXPIRE target v1.3.0 options
  --ctexpire-set value          Set conntrack expire to <value>
  --ctexpire-dec value          Decrement conntrack expire by <value>
  --ctexpire-inc value          Increment conntrack expire by <value>



[-- Attachment #2: CTEXPIRE.tar.gz --]
[-- Type: application/x-gzip, Size: 4672 bytes --]

RE: target for modifying conntrack timeout value

[Henrik Nordstrom]

On Mon, 6 Dec 2004, Richard wrote:

> Ok, I got the latest svn. However I have trouble to get a diff between it
> and my working copy. "svn diff" only diffs the existing files and does
> generate a patch for new files.

Have you "svn add":ed them?

> Anyway, I attached this tar.gz file which is extracted into netfilter
> directory. Then run "patch -p0 Makefile.diff".

You don't need to patch the Makefile. Just add a .<yourname>-test file 
(see existing ones as examples)

And you can place all the files in pom. Just move your iptables directory 
into your pom directory, next to the linux directory.

Regards
Henrik

RE: target for modifying conntrack timeout value

[Richard]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

> > Ok, I got the latest svn. However I have trouble to get a diff between
> it
> > and my working copy. "svn diff" only diffs the existing files and does
> > generate a patch for new files.
> 
> Have you "svn add":ed them?
Thanks, it works after I did 'svn add'.

> And you can place all the files in pom. Just move your iptables directory
> into your pom directory, next to the linux directory.

Ok, I attached both svn diff and tar.gz files. Not sure which one is more
acceptable.

Thanks,
Richard


[-- Attachment #2: CTEXPIRE.diff.gz --]
[-- Type: application/x-gzip, Size: 3458 bytes --]

[-- Attachment #3: CTEXPIRE.tar.gz --]
[-- Type: application/x-gzip, Size: 3890 bytes --]