setsockopt(2) behaviour in BSD sockets.
George P. Lekkas
lekkas at cernvax.UUCP
Tue Jul 19 01:27:45 AEST 1988
A question concerning the setsockopt(2) call. First I remind you that:
getsockopt, setsockopt - get and set options on sockets
setsockopt(s, level, optname, optval, optlen)
int s, level, optname;
char *optval;
int optlen;
When manipulating socket options the level at which the
option resides and the name of the option must be specified.
To manipulate options at the socket level, _l_e_v_e_l is speci-
fied as SOLSOCKET. To manipulate options at any other
level the protocol number of the appropriate protocol con-
trolling the option must be supplied. For example, to indi-
cate an option is to be interpreted by the TCP protocol,
l_e_v_e_l should be set to the protocol number of TCP. For
further information, see getprotoent(3n).
Trying to figure out how Internet sockets work/behave and
watching them closely, I decided to do a setsockopt at the TCP
protocol level, that is set the level=6. This call was made on
the socket returned from accepting a connection request, at the server side.
All sockets were of the SOCK_STREAM type and you can find this typical
client/server paradigm in the 4.3BSD Communications Primer.
Just add the setsockopt(msgsock,..) call after the
msgsock = accept() line. Optval and optlen were set to zero, optname
can be 0 or SO_DEBUG. It is not clear whether this kind of call is
supposed to produce output of any kind. My question and remark is
on the result: A simple user can cause a VAX (8530 on Ultrix 2.0-1 and
750 on 4.3BSD) to crash ("protection trap 9" or something)
Should this be so easy ? Is there a patch for it ? That is the
question. I know this is not a bug report, but I hope it's enough for
someone to answer me.
George Lekkas
lekkas at theseas.uucp NTUA, Athens, Greece,
lekkas at cernvax.uucp CERN-SPS Div., Geneva, Switzerland.
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list