Subject: Re: New sysctl "net.listen_backlog"?
To: Todd Vierling <tv@pobox.com>
From: Marc Slemko <marcs@znep.com>
List: tech-net
Date: 09/14/1998 12:40:02
On Mon, 14 Sep 1998, Todd Vierling wrote:

> On Mon, 14 Sep 1998, Marc Slemko wrote:
> 
> : > The kernel default for this value would be 5, _but_ the definition of
> : > SOMAXCONN in <sys/socket.h> would be changed to something intended to make
> : > reasonable use of an increased value by default (say, 32).  Since listen()
> : > silently reduces a larger-than-the-limit number automatically, this would
> : > not interfere with program operation.
> 
> : What is any modern OS doing defaulting to something tiny like 5 or 32?
> : That is very broken.
> 
> 5 is known and expected, and very reasonable for a machine that _isn't_ a
> server - it actually helps lower the chances of protocol level attacks at
> listening sockets.

If it has listening sockets, it is a server.

I'm not sure how it lowers the chances of attacks.  It certainly gives a
major increase in the chance that something like a routing problem (ie.
traffic can pass one way but not the other) can result in a single remote
system trying to send mail filling the backlog (since the test is done
against qlen+q0len, not just qlen) and making all further connections fail
until the old ones timeout.

> 
> The ability to change that at run-time is what I'm proposing here.

I understand what you are proposing, and it of course makes sense.
However, I am amazed that anyone can think it reasonable to have a default
of 5.  I also don't see the point of making it tunable but still having a
default hard limit as low as 32.