> 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
mouseat_private
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:36:07 PDT