Re: Linux inetd..

[mouse () RODENTS MONTREAL QC CA (der Mouse)]

> 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