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

["Brian J. Murrell" <netfilter@interlinx.bc.ca>]

[-- 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 --]