separation of sysctl and tcp-window-tracking patch?

separation of sysctl and tcp-window-tracking patch?

[netfilter]

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

There seems to be varied needs for netfilter specific /proc entries.
The tcp-window-tracking patch seems to me to have placed a /proc entry
point for netfilter most sanely at /proc/sys/net/ipv4/netfilter/.  I
would also like to have a sysctl/proc node to diddle with tunables in
my Amanda conntracking module.

Specifically the default of 180 seconds for a UDP stream is not long
enough on the control (master in netfilter parlance) connection of an
Amanda session, so I would like to override the master's timeout value
in my conntrack helper.  I have tested my theory with a hard coded
value and it work.  Now I would like to make it tunable by the
user/administrator.

I suppose I could pass an argument while loading the module, but using
sysctl (and/or /proc) just seems so much more sane.  But I digress,
greatly.

I am wondering if Jozsef and/or Harald would like to separate out the
creation of the /proc/sys/net/ipv4/netfilter/ node into a separate
patch for the rest of us to use, rather than having to make
tcp-window-tracking a prerequisite just to get a proc entry to use.

Thots?
b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: separation of sysctl and tcp-window-tracking patch?

[James Ralston]

I was catching up on back netfilter-devel messages and saw this.

I absolutely agree.  I would *really* like to be able to tune various
netfilter-related settings via /proc, regardless of my opinions on the
tcp-window-tracking patch.

(My specific need is related to DNS service: namely, in many cases, 30
seconds to establish a UDP session simply isn't enough time to permit
a reply to an outstanding DNS query.  I want to be able to up that
timeout to something closer to 60 or 120 seconds.)

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA

On 2002-10-31 at 21:12:36-0500 netfilter@interlinx.bc.ca wrote:

> There seems to be varied needs for netfilter specific /proc entries.
> The tcp-window-tracking patch seems to me to have placed a /proc
> entry point for netfilter most sanely at
> /proc/sys/net/ipv4/netfilter/.  I would also like to have a
> sysctl/proc node to diddle with tunables in my Amanda conntracking
> module.
> 
> Specifically the default of 180 seconds for a UDP stream is not long
> enough on the control (master in netfilter parlance) connection of
> an Amanda session, so I would like to override the master's timeout
> value in my conntrack helper.  I have tested my theory with a hard
> coded value and it work.  Now I would like to make it tunable by the
> user/administrator.
> 
> I suppose I could pass an argument while loading the module, but
> using sysctl (and/or /proc) just seems so much more sane.  But I
> digress, greatly.
> 
> I am wondering if Jozsef and/or Harald would like to separate out
> the creation of the /proc/sys/net/ipv4/netfilter/ node into a
> separate patch for the rest of us to use, rather than having to make
> tcp-window-tracking a prerequisite just to get a proc entry to use.
> 
> Thots?
> b.

Re: separation of sysctl and tcp-window-tracking patch?

[Jozsef Kadlecsik]

On Thu, 12 Dec 2002, James Ralston wrote:

> I absolutely agree.  I would *really* like to be able to tune various
> netfilter-related settings via /proc, regardless of my opinions on the
> tcp-window-tracking patch.
>
> (My specific need is related to DNS service: namely, in many cases, 30
> seconds to establish a UDP session simply isn't enough time to permit
> a reply to an outstanding DNS query.  I want to be able to up that
> timeout to something closer to 60 or 120 seconds.)

Please note, that the timeout settings via /proc introduced in the
tcp-window-tracking patch are global. You cannot raise the UDP timeout
values just for DNS.

Also, we have to handle the backward compatibility issue of
/proc/sys/net/ipv4/ip_conntrack_max, if the introduction of
/proc/sys/net/ipv4/netfilter/ is accepted.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: separation of sysctl and tcp-window-tracking patch?

[James Ralston]

On Thu, 12 Dec 2002, Jozsef Kadlecsik wrote:

> Please note, that the timeout settings via /proc introduced in the
> tcp-window-tracking patch are global.  You cannot raise the UDP
> timeout values just for DNS.

That's true.  But on dedicated nameservers (the situation I care
about), I don't care if all UDP connections on the system receive the
higher limit.

> Also, we have to handle the backward compatibility issue of
> /proc/sys/net/ipv4/ip_conntrack_max, if the introduction of
> /proc/sys/net/ipv4/netfilter/ is accepted.

True.

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA

Re: separation of sysctl and tcp-window-tracking patch?

[Denis Ducamp]

On Thu, Dec 12, 2002 at 03:05:33AM -0500, James Ralston wrote:
> (My specific need is related to DNS service: namely, in many cases, 30
> seconds to establish a UDP session simply isn't enough time to permit
> a reply to an outstanding DNS query.  I want to be able to up that
> timeout to something closer to 60 or 120 seconds.)

If your DNS servers serve zones then make them send requests from the udp/53
port, then late replies are accepted as requests by the filter.

Denis Ducamp.

Re: separation of sysctl and tcp-window-tracking patch?

[Brian J. Murrell]

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

On Thu, 2002-12-12 at 04:02, Jozsef Kadlecsik wrote: 
> On Thu, 12 Dec 2002, James Ralston wrote:
> 
> > (My specific need is related to DNS service: namely, in many cases, 30
> > seconds to establish a UDP session simply isn't enough time to permit
> > a reply to an outstanding DNS query.  I want to be able to up that
> > timeout to something closer to 60 or 120 seconds.)

I had this problem with the Amanda protocol, but it was with the UDP
streaming timeout.  It was not long enough to allow an Amanda client to
go do it's work and still respond to the server when it was done.

Fortunately (for this situation), the Amanda protocol requires a helper,
so I just upped the timeout on the connection in the helper.  But this
led me to think about UDP timeouts in general.

You might want to refer to this message:

http://lists.netfilter.org/pipermail/netfilter-devel/2002-September/009259.html

> Please note, that the timeout settings via /proc introduced in the
> tcp-window-tracking patch are global. You cannot raise the UDP timeout
> values just for DNS.

Indeed.  I had thought about this when I was doing my Amanda
modification for the UDP streaming timeout on it's connection.  For UDP
timeouts in general I had originally thought of doing this with
load-time module parameters.  Something along the lines of:

# insmod ip_conntrack.o udp_timeouts="53=60,123=10"

which would be added to a table already defined in
ip_conntrack_proto_udp.c with a set of common defaults.

This could be done via proc too however.  Maybe something like:

# cat /proc/sys/net/ipv4/netfilter/udp_timeout
default=30
53=60
123=10

to see the current timeout table and

# echo "default=45,520=30" > /proc/sys/net/ipv4/netfilter/udp_timeout

to set/modify entries in the table.

Of course we have two udp timeouts to deal with, initial UDP connection
setup timeout and the UDP streaming timeout.  Perhaps two different
/proc nodes.

> Also, we have to handle the backward compatibility issue of
> /proc/sys/net/ipv4/ip_conntrack_max, if the introduction of
> /proc/sys/net/ipv4/netfilter/ is accepted.

Right.  But let's not let this be a lone issue holding-up on moving
forward with general netfilter tunables via proc.

b.



-- 

Brian J. Murrell <netfilter@interlinx.bc.ca>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: separation of sysctl and tcp-window-tracking patch?

[James Ralston]

On 12 Dec 2002, Brian J. Murrell wrote:

> I had this problem with the Amanda protocol, but it was with the UDP
> streaming timeout.  It was not long enough to allow an Amanda client
> to go do it's work and still respond to the server when it was done.
> 
> Fortunately (for this situation), the Amanda protocol requires a
> helper, so I just upped the timeout on the connection in the helper.
> But this led me to think about UDP timeouts in general.

Well, the best way to solve this particular problem for DNS traffic
would be to use a helper.  Have the helper use a table to track the
state of DNS queries and replies via the 16-bit identifiers.  That
way, a DNS response that took more than 30 seconds could still be
permitted as RELATED traffic, by matching the ID of reply to the ID of
the query.

> # insmod ip_conntrack.o udp_timeouts="53=60,123=10"
> 
> [...]
> 
> This could be done via proc too however.  Maybe something like:
> 
> # cat /proc/sys/net/ipv4/netfilter/udp_timeout
> default=30
> 53=60
> 123=10
> 
> [...]
> 
> Of course we have two udp timeouts to deal with, initial UDP
> connection setup timeout and the UDP streaming timeout.  Perhaps two
> different /proc nodes.

While this will work, I suspect that a fair number of protocols could
be adequately supported by using helpers.

Failing a helper, I'm unable to come up with anything better than
adjusting timeouts on a per-port basis...

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA

Re: separation of sysctl and tcp-window-tracking patch?

[Patrick Schaaf]

> Failing a helper, I'm unable to come up with anything better than
> adjusting timeouts on a per-port basis...

What about a single new target, CTTIMEOUT or something, having a single
parameter, a relative timeout in seconds. Whenever that target hits,
and we have a connection hanging off our skb, the connection's timeout
will be refreshed to now+the_given_timeout.

This could be equally used to lower TCP ESTABLISHED timeouts for
certain uses, and for extending the UDP timeouts discussed here.
You would use normal, arbitrary matches to select _which_ packets
should receive the treatment.

I have not thought about the interplay with the current automatic
timeout selection. Anybody?

best regards
  Patrick

Re: separation of sysctl and tcp-window-tracking patch?

[Brian J. Murrell]

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

On Fri, 2002-12-13 at 07:06, Patrick Schaaf wrote:
> > Failing a helper, I'm unable to come up with anything better than
> > adjusting timeouts on a per-port basis...
> 
> What about a single new target, CTTIMEOUT or something, having a single
> parameter, a relative timeout in seconds. Whenever that target hits,
> and we have a connection hanging off our skb, the connection's timeout
> will be refreshed to now+the_given_timeout.

I guess because the idea of a parameter to set the timeout has been
floated before (by me and by others before me) and turned down (by
Rusty) in favour of a (tunable) table in the UDP conntracker.  This
would be to further autoconfiguration which Rusty is a great fan of.


> I have not thought about the interplay with the current automatic
> timeout selection. Anybody?

Which is probably why doing it in the udp conntracker, in a tunable
table is the current way of thinking.  Should not be too difficult in
fact.  I would attempt it myself if I could get a decent stretch of
hacking time.

b.

-- 
Brian J. Murrell <netfilter@interlinx.bc.ca>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]