stanonik@NPRDC.ARPA.UUCP (02/18/87)
Hello, 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. We've hacked a version of the 4.3bsd telnet server, which omits the terminal-type negotiation, and put it on another port, but can't convince the 1186 to try the alternate port. Anyone else encountered this (the xerox folks say other sites have 1186s telneting to 4.3bsd machines)? Any idea how to convince the 1186 to use an alternate port for telnet? 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"?
minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP (03/01/87)
> 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
stanonik@NPRDC.ARPA.UUCP (03/03/87)
Thanks. I asked about the correctness of 4.3bsd's telnet server because I was uncertain about what a host should do between sending a telnet option request and receiving a response. The rfc doesn't seem to say what the host should do, although now I notice that it (rfc 854) does say what the host may do: "may wish to buffer data, after requesting an option, until it learns whether the request is accepted or rejected". In effect, that is what 4.3bsd does, buffers all data (well, it throws some away if the buffer fills) until receiving a response. Thanks, Ron stanonik@nprdc.arpa