From owner-freebsd-hackers  Thu Feb 20 17:24:48 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA23954
          for hackers-outgoing; Thu, 20 Feb 1997 17:24:48 -0800 (PST)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23942
          for <freebsd-hackers@freebsd.org>; Thu, 20 Feb 1997 17:24:45 -0800 (PST)
Message-Id: <199702210124.RAA23942@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA186048265; Fri, 21 Feb 1997 12:24:25 +1100
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: "connection refused"
To: davidn@labs.usn.blaze.net.au (David Nugent)
Date: Fri, 21 Feb 1997 12:24:25 +1100 (EDT)
Cc: freebsd-hackers@freebsd.org
In-Reply-To: <19970221082221.50024@usn.blaze.net.au> from "David Nugent" at Feb 21, 97 08:22:21 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from David Nugent, sie said:
> 
> On Feb 02, 1997 at 07:46:13AM, Darren Reed wrote:
> > In some mail from John-Mark Gurney, sie said:
> > > > Ok. Then recvmsg() should be used without (instead of) accept()?
> > > 
> > > it seems that accept() does do what you want.....  directly from the
> > > accept() man page:
> > > For certain protocols which require an explicit confirmation, such as ISO
> > > or DATAKIT, accept() can be thought of as merely dequeueing the next con-
> > > nection request and not implying confirmation.  Confirmation can be im-
> > > plied by a normal read or write on the new file descriptor, and rejection
> > > can be implied by closing the new socket.
> 
> Yes, that's how I read it too, the first time. :)
> 
> > > it seems you can accept() a conntection... verify were it is coming from
> > > and then close and it will be rejected...  as it turns out this isn't
> > > true...  (I just wrote a test program to test it)...
> 
> As did I, and hence my question.

Well, if you read the kernel source (tcp_input.c), it becomes more obvious
about why you can't stop it before it goes "connection established".  The
socket is in LISTEN, packet comes in, gets bumped upto SYN_RECEIVED. and
SYN-ACK is sent back (so the other side goes to ESTABLISHED).  From my
recollection of the code, there are no hooks for going to a user.

Darren