[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using rel 7.0 with 4.3 (telnet)
Date: Fri, 5 Dec 86 17:04 PST
From: Richard Lamson <rsl@CERRIDWYN.SSF.Symbolics.COM>
Date: Fri, 5 Dec 86 15:05:52 EST
From: firstname.lastname@example.org (Mark Bromley)
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Has anyone else reported problems getting the symbolics to
talk to 4.3BSD with telnet? apparently options negotiation
fails - the configuration of the terminal on the UNIX side
is completely wrong for the symbolics (echoing all the
characters, not doing real carrage returns, etc.)
The echo processing negotiation in the symbolics telnet user program
is broken. The problem is that it is treating DO ECHO and DON'T
ECHO requests by the server as pertaining to local echoing, when in
fact they pertain to echoing over the network. As the telnet user
program never sends WILL ECHO any DO ECHO received by the user must
be a request from the server and not a response.
Sorry, you haven't read the documentation correctly. The TELNET
protocol is completely symmetrical. Either end may request that the
other DO echoing, and that end either WILL or WON'T echo. This is
pretty well explained in RFC's 854, 855 and 857.
But I think I have read the documentation correctly. Upon receipt of a DO
ECHO IAC from the telnet server, there are two possibilities:
(1) The DO ECHO is in response to a WILL ECHO from the telnet user program.
(2) The DO ECHO is a request from the server.
An examination of the telnet code will show that it never sends WILL ECHO.
Thus any DO ECHO received by the telnet user is a request from the server.
Now quoting from RFC857, the meaning of DO ECHO is:
"The sender of this command REQUESTS that the receiver of this
command begin echoing, or confirms that the receiver of this
command is expected to echo, data characters it receives over the
TELNET connection back to the sender."
Thus any DO ECHO received by the telnet user program is a request by the
server that the user program echo characters it receives OVER THE TELNET
CONNECTION FROM THE SERVER back to the server. The problem is that the
symbolics telnet user code is interpreting this DO ECHO as a request that it
begin echoing characters locally, ie that it should locally echo each
character that is typed in the Terminal window. So it sets up local echoing
and sends DON'T ECHO to the server which dutifully turns off echoing over
the network and responds WON'T ECHO. We end up with local echoing of
everything that is typed in a terminal window, including passwords. Now
almost every BSD .login (BSD unix equivalent of lispm-init.lisp) invokes
tset, which is supposed to set up the terminal state. One of the things
tset does is unconditionally turn echoing on. So you end up with a
terminal window where the password is echoed and everything you type is
echoed twice. What should have happened here is that the Lisp machine
should send WON'T ECHO in response to DO ECHO as it is not set up to echo
characters it receives over the telnet connection back to the server.
The 4.3bsd telnet server sends out a DO ECHO request in an attempt
to find out if the other end is a 4.2bsd machine.
This should have been a clue to you that someone was using an
undocumented feature of an otherwise elegant protocol to learn something
that isn't part of the protocol. This is sometimes known as a kludge.
Granted it is a kludge, but it is not a kludge that should break correct
telnet implementations. Presumably 4.2 BSD telnet is the only one brain
damaged enough to send WILL ECHO in response to a DO ECHO request from the
Now for a question from me. I have a patch for this problem and would like
to make it generally available. The patch involves a small amount (~60
lines) of code which is copyrighted by Symbolics but is part of the general
source distribution which comes along with any system. What do I have to do
to cover my tail in making this publicly available?
How about if you send it to Customer-Reports@Symbolics.COM (or
@Symbolics.ARPA) and we'll see if it's installable as is. The last I
heard we had just received our copy of 4.3bsd and were trying to install
This really doesn't answer my question. I would like to make this availabe
NOW, not N months from now when you get around to distributing it. Note
that the patch is to Symbolics code, not 4.3 code. Your answer does bring
up another question though. What is the "proper" procedure for reporting
problems/bugs to Symbolics via E-mail? What is the difference between HOSS