[1105] in linux-net channel archive
Re: heavily-accessed site w/ random hangs on specific port... suggestions?
daemon@ATHENA.MIT.EDU (Ian Jackson)
Fri Sep 15 23:17:01 1995
Date: Fri, 15 Sep 95 14:03 BST
From: Ian Jackson <iwj10@cus.cam.ac.uk>
To: Nick Simicich <njs@scifi.maid.com>
Cc: "Matti E. Aarnio [OH1MQK]" <mea@mea.cc.utu.fi>,
Michael Brennen <mbrennen@puddytat.intecom.com>,
linux-net@vger.rutgers.edu, emo@cica.cica.indiana.edu
Nick Simicich writes:
> This is my guess: I think that you have received only the first part of
> the TCP three part handshake, and that you have transmitted the second
> part, but you never got the third part.
>
> You have enough slots in this state that all of your listen() slots are
> full.
I have been involved in setting up a MUD site which had similar
problems. The solution was quite simple: recompile the kernel to
change the `if (backlog > 5) backlog = 5' in af_inet.c to use a larger
number, and change the server too. We changed it to 30, and the
system now seems to work much better.
> [...]
> According to the listen()/accept() manpages, there are two possible legal
> behaviours when all listen slots are full.
>
> a) You can send RSTs, to tear down the other end's partially opened
> connection.
>
> b) You can throw away the SYN packets, assuming that the other end will
> retransmit, and hopefully you will have a listen() slot when the
> retransmit arrives.
The latter (b) is what Linux actually does; IMO this is correct. It's
also what most other Unix TCP's do.
> Reduce the chances of net problems causing this by increasing the size of
> the listen queue. This won't help if you are actually attacked.
Right. You can use `netstat' to find out where the `bad' connections
are apparently coming from, but that won't help if the source
addresses are all clever lies.
Ian.
