On Monday 23 August 2004 23:49, Mike Frantzen wrote:
> > That will not help you to solve the problem. It will only cause some
> > troubles to valid connection states.
>
> Nope. The point of the adaptive limits was to only start penalizing
> things when the firewall is overloaded. Read-on
When the firewall is overloaded someone trying to start a valid connection
will be penalized exactly like a box 0wned by some worm/virus...
> 3.5 and below still allocate PF state entries out of kmem_map which is
> limited to 64meg of ram; the adaptive limits are necessary. Tedu@
> worked his mojo in -current so that the 64M limit no longer applies and
> it can take advantage of extra ram. IIRC the theoretical max states on
> 3.5 is only 250K entries. That is only 55 connections per host in his
> setup.
I prefer a deterministic setup than a unforeseeable one.
By the way, limiting the number of states used by p2p clients to connect
outside the campus is not so bad, because it lets you save a bit of
bandwidth.
> Things like p2p and blasting worms leave tons of connections in the
> FIN_WAIT_2 or TIME_WAIT states which are only removed when they time
> out (a rule of thumb is ten closed states waiting to be expired for
> every one state still established).
>
> With gnutella running, my laptop has 208 PF states and 190 of which are
> in fin-wait or closed.
You can lower some specific timeout limits and you'll always know what your
firewall is doing.
tcp.closing
The state after the first FIN has been sent.
tcp.finwait
The state after both FINs have been exchanged and the connec-
tion is closed. Some hosts (notably web servers on Solaris)
send TCP packets even after closing the connection. Increas-
ing tcp.finwait (and possibly tcp.closing) can prevent block-
ing of such packets.
tcp.closed
The state after one endpoint sends an RST.
Ed
