[5800] in bugtraq
Re: Linux inetd..
daemon@ATHENA.MIT.EDU (der Mouse)
Mon Dec 15 12:57:31 1997
Date: Mon, 15 Dec 1997 12:31:43 -0500
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@NETSPACE.ORG
> Linux's accept behaviour has been that way (returning before the
> connection gets to ESTABLISHED) for quite some time. [...]
This is neither here nor there; ever since (on a very old version of
Ultrix) I saw the notion, I've thought this should be available as an
option.
> One of the really annoying things about accept() behaving like this
> is that the remote socket information can be gone before accept() has
> a chance to store it in your `sockaddr_in', requiring a packet
> sniffer of some variety before you know who/what/where is scanning
> your active ports.
This is not a problem with accept() returning early or not; the same
problem exists with a host completing the three-packet handshake and
then RSTing the connecting very soon afterwards. The kernel should
_never_ throw away the peer address as long as user-land can still
potentially do a getpeername() (which is what the second and third
arguments to accept() amount to), regardless of what the peer does.
In short, I believe this problem (lack of peer info, whether at
accept() or getpeername() time) is a kernel bug.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
