Hi!

I just changed the maximum number of connections that the conntrack module can handle, but I did so by compiling it as a module (with all of it's dependecies) and adding this lines to the /etc/init.d/S45firewall:

#Estas dos siguientes agregadas por mi para incrementar el número de conexiones
#a 131072

#The hashsize is important, and should be a prime number
#It should be bigger than the numer of connections, or else
#you will get a "processor-eating" module (I really mean it).

/sbin/insmod ip_conntrack hashsize=131101
/bin/echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max

#Los siguientes, pues el resto de modulos de conntrack, lastima que no esta
#el automontador de modulos, pero bueno.

/sbin/insmod iptable_nat
/sbin/insmod ip_conntrack_ftp
/sbin/insmod ip_conntrack_h323
/sbin/insmod ip_conntrack_irc
/sbin/insmod ip_conntrack_mms
/sbin/insmod ip_conntrack_proto_gre
/sbin/insmod ip_conntrack_pptp
/sbin/insmod ip_conntrack_tftp
/sbin/insmod ip_nat_ftp
/sbin/insmod ip_nat_h323
/sbin/insmod ip_nat_irc
/sbin/insmod ip_nat_mms
/sbin/insmod ip_nat_pptp
/sbin/insmod ip_nat_proto_gre
/sbin/insmod ip_nat_snmp_basic
/sbin/insmod ip_nat_tftp
/sbin/insmod ipt_MASQUERADE
/sbin/insmod ipt_REDIRECT
/sbin/insmod ipt_conntrack

Can I do all of this "in-kernel" without having to compile it as module?, if not, can this be added to the "official" OpenWRT? (compile conntrack as module, and load it somewhere in the init scripts), well, not for 131072 connections, but at least for 8192, or at least give an "easy" method to increase it (I know about the /proc/sys/net/ipv4/ip_conntrack_max file, but if you increase it there and you don't increase the hashsize parameter you will have the processor very busy).

Hope this helps someone, and thanks for any help (I'm getting tired of having to modify the source every time there is a new version).

There is a correction, a limit of 131072 isn't possible with WRT54GS, you could only get to about 51000.

I would like to add that it is good to lower the value
of /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

Because the default timeout is 5 days which is too big for a dialup-line i think. If you have running any file-sharing
application which is not terminating the tcp-connects correctly
each connect will persist for 5 days ...

I do:
# 1 hours TCP-Conntrack Timeout
echo "$((1*3600))" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
and i have no negative side-effects ...

mmmm...... I have never tried that, but I think it worth a try.  Please, try to do a wget to download a large file (say: http://ftp.knoppix.nl/os/Linux/distr/kn … 08-EN.iso)
and look if the connection is lost before it finish the download.

Good advice, but I need to test it too (if you don't have it, you should download knoppix, it is very usefull as a recover cd).

I don't have the time right now to test this, but i'm sure that
5 days is too long. 1 hour could be to short but you are free
to choose another reasonable value.

For me 1 hour seems to be fine. I don't use the old-fashioned"
ftp-protocol. Bittorent and my openvpn-tunnel runs fine.

My Provider automatically disconnect my dsl-line after 24
hours, so 24 hours would be the best choose.

As soon as i notice some kind of transfer-disconnects
because of the short timeout i will set it to 24 hours and
keep you informed.

Checkpoint (you know, the big firewall comp) says:

Hi,

I did this some time ago, but I did modify directly the kernel source, in buildroot/build_mipsel/linux/net/ipv4/netfilter/ip_conntrack_core.c

There you can change the value for hashsize as ip_conntrack_htable_size variable. Btw, I think you are wrong in setting hashsize so big, in kernel source you can see conntrack = hashsize * 8.

Hope that helps you.