On Mon, 14 Sep 1998, Jonathan Stone wrote:

> 
> I think we're down to arguing over the defaults.  By the time I finish
> writing this it's probably redundant, but I'd go for:
> 
>    *  a default  SOMAXCONN of 128 or more;
>    *  document the  knob in the listen(2) manpage where it's
> 	currently a constant;
>    *  add an rc.conf variable and rc machinery to set
>       the knob via sysctl;
>    * perhaps make the upper limit tunable (add #ifndef/#endif in socket.h)

I really see no point in making the upper limit tunable.


[...]
> I think Todd's point is that many netBSD boxes are from the same
> hardware generation where 5 was an adequate value for SOMAXCONN, and
> for those boxes, 128 is Too Big, and 32 may be better.  Todd is
> worrying about is someone sending a "fork bomb" to a daemon by opening
> full-fledged connections[*] at a higher rate than, say, an 11/750 or a
> 16Mhz i386 can fork() off children.  So Todd wants the default value
> enforced by listen(2) to be conservative to prevent DoS attacks.
> 
> I sorta buy that, _if_ anyone has acutally seen this causing thrashing
> and DoS.

I really don't buy that.  If someone wants to do that, they just have to
open connections as quickly as they can; those that overflow the backlog
will be ignored (ie. no response to the SYN), so the attacker will just
open a new one.  It really doesn't stop anything.

The only real DoS I can think of realted to too-high listen backlog is if
you are under SYN attack and don't have appropriate protection to avoid
bad O(N^2) or similar things.

> The other problem is that if the compile-time SOMAXCONN is too low,
> you need to recompile all your apps to get its listen(2) calls to ask
> for more than the default SOMAXCONN (i.e., 128 now).  So we don't want

Why would you have to do this?

Compile Apache on a kernel with SOMAXCONN set to 128.  Set the sysctl to
511.  Apache will pass backlog param of 511 just fine and everything
should work just fine.  The only except is if you have your libc checking
SOMAXCONN, but that would just be broken.

This is only a problem for apps that check SOMAXCONN at compile time and
arbitrarily limit their setting to that, and there are few good reasons
for any app to do that.

SOMAXCONN would then become only a legacy thing, as it always should have
been.  It makes no sense to have it hardcoded, so whatever value you pick
for your include file will be "wrong", but you may as well make it used
for the default so it is at least right the default of the time.