setsockopt(2) behaviour in BSD sockets.

[George P. Lekkas]

 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.