Subject: Re: New sysctl "net.listen_backlog"?
To: Todd Vierling <email@example.com>
From: Marc Slemko <firstname.lastname@example.org>
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.