Joined: 03 Jan 2007 Posts: 76 Location: Sweden, Stockholm
Posted: Tue Jan 26, 2010 14:10 Post subject: K2.6 Increase Maximum Connections ip_conntrack_max hashsize
Here is a solution for increasing the maximum number of connections in Kernel 2.6:
K2.6 is very different regarding ip_conntrack_max (IP Filter Maximum Ports in the GUI) and it's hash table compared to the older kernel.
ip_conntrack_max sets the maximum number of connections that can be kept at one time. Most people here seems to decrease the default timeout (3600s) for these connections (which results in other problems) instead of increasing the maximum value.
On routers with large amount of RAM (32 MB for example) one could increase this by 10 times from the default max of 4096 without any problem.
From what I understand you also have to increase the hash table where these are stored in order to benefit from this increase. In the older kernel this was not possible since one would have to set this value before booting (and there was no nvram setting for that?).
Although in K2.6 one can change booth of these in realtime dynamically without restarting any process. A hashsize equaly large to the conntrack_max, has the best performance as I understand. Also since K2.4.21 the hashsize performs best with a value that is a power of 2 ex. 2^14 = 16384. (I have also used this as an example)
Since K2.4.23 (and newer), to change ip_conntrack_max:
But none of these will be stored after a reboot, since the values are stored in RAM.
Permanently change ip_conntrack_max, ether use the webgui or write:
nvram set ip_conntrack_max=16384
nvram commit
reboot
I haven't found any way to permanently change the hashsize parameter. Although since you now in K2.6 can change it in realtime, you can just add it to your startup script and it should do the job.
During the test you see in the image (14-16k connections), the router used up some 5 MB of the free RAM (so make sure you have enough RAM). Also my computer almost crashed when it opened up 16k connections (froze for some seconds), could be a software problem though. _________________ WRT320N
Last edited by ev1te on Sat Jan 30, 2010 13:04; edited 3 times in total
Posted: Sat Feb 06, 2010 1:12 Post subject: Breaks the WebUI
Max Connections (ip_conntrack_max) limited to only 4k in the default firmware is a non-starter where I am, as we tend to have tens of thousands of connections at any given moment (we develop p2p software).
I'm not sure where the best place to report this is, but once you increase the ip_conntrack_max value it breaks the web ui in several places. I've attached a screenshot of this. I'm guessing it's something to do with the value being more than four digits...
I'm not sure why the limit is set to max 4096 by default, as that's extremely low, especially given the current crop of hardware, but we're not the only ones complaining: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=63623
If max conns could be increased without breaking the webui, I'd switch to ddwrt for our office in a heartbeat.
Oh, it definitely has nothing to do with stale browser cache. Here's some captures on a totally different browser on a totally different os. The Active Clients list also never gets filled.
I can reproduce 100% reliably by starting with a virgin ddwrt image, and simply running
Joined: 03 Jan 2007 Posts: 76 Location: Sweden, Stockholm
Posted: Sun Feb 07, 2010 16:12 Post subject:
I am using 2.6 (you have 2.4) which might explain a few things.
From what i understand you can not only increase the ip_conntrack_max value in linux, you also have to increase the hash table for these values. Which is impossible to to in the 2.4 version kernel without rebuilding the firmware (but still possible in 2.6 since you can modify the value while the router is running).
I have been running 16384 connections max without any setbacks for a couple of weeks now. _________________ WRT320N
The ability to dynamically adjust the hash size settings only applies to kernel 2.6.14 and higher. Kernel 2.4 builds can only adjust it as a compilation option so you would have to compile your own build to gain more than 4096 conntrack entries. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
After reboot webui does not display active connections or memory information.
Thoughts?
If you read my first post, you will see that that it only works for the new Linux kernel (2.6.20 and forward), and you have DD-WRT v24-sp2 (which is 2.4.x something)
Look if the new firmware with the new kernel is available for your router. Otherwise I don't know if it is possible to fix it. _________________ WRT320N
Yeah, RT-N16 only supports k2.6 so there's no way you have k2.4. Iirc k2.6 explicitly say it in the version string on the status page but it seems to have been missing in the first screenshot for whatever reason.
It might be that the nvram variable + startup script is causing trouble because it's doing things in the wrong order. Try removing all of it, reboot, and then run these commands via telnet in the order below so that the hash size is increased before you try raising the conntrack limit.
echo "16384" > /sys/module/nf_conntrack/parameters/hashsize
echo "16384" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Joined: 03 Jan 2007 Posts: 76 Location: Sweden, Stockholm
Posted: Mon Feb 08, 2010 9:30 Post subject:
Sorry for the misunderstanding, I must have mixed up the v24 with K24.
I am using a nvram value of 16384 for ip_conntrak_max.
My startup script begins a "sleep" in order for all the vital functions to start properly first:
1) In order for the UI to pick up the max connection increase, one must use 'nvram set' (at least on the rt-n16), although I suspect that setting the proc value via 'echo' is enough to get things working behind the scenes.
2) It appears that issuing 'nvram commit' afterwards is what breaks things for me, so I instead saved the config via the gui save/apply settings/reboot router buttons.
I'm now running with hashsize and ip_conntrack_max both set to 65536, which I'll be testing this week with some real world load.
Joined: 03 Jan 2007 Posts: 76 Location: Sweden, Stockholm
Posted: Wed Feb 10, 2010 20:28 Post subject:
nolar wrote:
OK, got it working, without the broken ui!
1) In order for the UI to pick up the max connection increase, one must use 'nvram set' (at least on the rt-n16), although I suspect that setting the proc value via 'echo' is enough to get things working behind the scenes.
2) It appears that issuing 'nvram commit' afterwards is what breaks things for me, so I instead saved the config via the gui save/apply settings/reboot router buttons.
I'm now running with hashsize and ip_conntrack_max both set to 65536, which I'll be testing this week with some real world load.
That seems weird, doesn't the gui use nvram commit to save values as well?
Also 65536 connections would use a lot of RAM, probably around 20 MB, so try and keep track of the RAM usage while you benchmark the settings. _________________ WRT320N
Last edited by ev1te on Thu Feb 11, 2010 21:29; edited 1 time in total