Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!UCBVAX.BERKELEY.EDU!minshall%opal.Berkeley.EDU
From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: xerox -> 4.3bsd telnet
Message-ID: <8703010139.AA04150@opal.Berkeley.Edu>
Date: Sat, 28-Feb-87 20:39:03 EST
Article-I.D.: opal.8703010139.AA04150
Posted: Sat Feb 28 20:39:03 1987
Date-Received: Sun, 1-Mar-87 16:47:49 EST
References: <8702181909.AA15985@pacific.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 43
Approved: tcp-ip@sri-nic.arpa

> We recently installed a xerox 1186 (dandytiger?) running koto
> release 2.0.  Telneting from the 1186 to our vax 780 running
> 4.3bsd hangs, apparently because the 1186 doesn't respond to
> the vax telnet server's "do terminal-type" negotiation.  The
> 4.3bsd telnet server waits in a loop for the "will/won't terminal-type"
> response, processing options, but not starting a login process.
> That seems unforgiving (although seemingly legal) from 4.3bsd.
...
>					Or, is 4.3bsd wrong
> to "hang" waiting for the "will/won't terminal-type" response?
> 
> Thanks,
> 
> Ron Stanonik
> stanonik@nprdc.arpa
> 
> ps.  The 1186 also seems to violate the rfcs by sending the
> "terminal-type is" subnegotiation without first receiving
> a "terminal send".  Or maybe it thinks that is a suitable
> response to "do terminal-type"?

I wrote some of the code in the 4.3 telnet server.
I didn't want to start up the login process until I got a reply
to the terminal type negotiation, since a positive reply would
allow me to set up the terminal type in the login processes
environment.  In an engineering sense, I could have said
"if no answer within N seconds, skip the terminal type negoitiation".
I didn't do that.  In a more perfect world, I probably would have.

Now, as for your "1186", if it listens to "do terminal type"
by replying "terminal type is", then it is out of spec, and you
should ask your vendor for a fix.  RFC930 is quite specific on
this point (as well it should be).

In summary, the 4.3 implementation is legal and even "reasonable"; it
is not as robust as could be.  Your description of the "1186"'s
behaviour leads me to believe that it is not implementing the protocol
correctly.


Yours,

Greg Minshall