The timers are used for table mapping timeouts of TCP states.If we didn't have them, mappings would stay in the kernel forever and eventually we'd run out of memory.I'll try to put some more effort into working on the 2.6.x kernel, however since it's still too unstable of us, our main focus remains on the 2.4.x kernel.[And before you ask: No, we don't have the time (money wise) to invest into bug-hunting and reporting problems regarding 2.6.x kernels on high-end server machines.
I've backported it and also improved it quite a bit (service pool) and so we're currently completely out of sync :).
My code has this vulnerability, but I'm not sure a helper app would be any more secure (sudo is a helper app.) liuk001 (at) gmail (dot) com Oct 12 2005 Jeremy, this is a good point.
I wrote it as a quick and dirty hack without security in mind.
However, the beforementioned timers regarding packet filtering, NAPT and load balancing and are meant as a means to map expected real TCP flow timeouts.
Since there is no socket (as in an endpoint) involved when doing either netfilter or IPVS, you have to guess what the TCP flow in-between (where you machine is "standing") is doing, so you can continue to forward, rewrite, mangle, whatever, the flow, _without_ disturbing it.
Browsing through the code recently I realised that the state transition code in (which I consider a great invention, BTW) one would assume that IPVS timeouts are more closely timed to the actually TCP flow.