Subject: Re: erroneous ack packet, ideas please?
To: None <grefen@hprc.tandem.com>
From: Andrew Brown <codewarrior@daemon.org>
List: tech-net
Date: 07/17/1997 13:50:16
>> i've got my box at home to the point where accept() returns after the
>> first syn (via a setsockopt() on the "master" socket), subsequent syns
>> are simply "absorbed", and i can then *choose* to keep the connection
>> and finish the tcp handshake (via an ioctl() on the "slave" socket).
>> after this, it behaves like a completely normal socket except for the
>> extra ack packet that i don't understand.
>
>Why ioctl() ?? Have a look at man accept(2). 

i have looked, and i've decided that it doesn't seem to do what i want.
i saw the following two paragraphs...

     For certain protocols which require an explicit confirmation, such as ISO
     or DATAKIT, accept() can be thought of as merely dequeuing 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.

     One can obtain user connection request data without confirming the con-
     nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-
     zero msg_controllen, or by issuing a getsockopt(2) request.  Similarly,
     one can provide user connection rejection information by issuing a
     sendmsg(2) call with providing only the control information, or by call-
     ing setsockopt(2).

but they don't apply to tcpip as far as i can tell.  therefore, i have
to do it another way.

>There is a way to accept/reject connections for ISO protocols, without 
>special ioctls.

not that i know much about the iso protocols, but i would have to
assume that since i'm not using iso protocols, oddities/features of
those protocols won't apply?

>A program not expecting a socket in this state (inherting the socket from a
>parent process) would just work (only may block longer on the initial read or 
>write).

i considered this (having a close() on a slave of an eager socket send
the reset, and having anything else (read, write, sendto, ...) finish
the connection, but didn't want to get involved in every single thing
right off the bat.

>I've haven't checked how much of the needed code is generic socket code
>and how much is in netiso.

so far, all the stuff i've changed has been in src/sys/netinet, with
the exception of the ioctl addition to src/kern/sys_socket.c and
src/sys/sockio.h...

-- 
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."