gm@ionic.UUCP (Greg Miller) (11/22/90)
I'm in the midst of writing my own tcp/ip implementation, and have been
caught up with what seems to be a problem - determining who exactly
does any echoing in a telnet session.
I've read the RFC covering the telnet ECHO option (RFC 857), and thought
that I understood it. This explanation is an oversimplification, but
shows the way I interpreted it:
(There's no need to explain the need to respond to a "WILL/WONT" with a
"DO/DONT" rather than the other-way-around; I'm fully aware of that, and
make use of it. I don't include it here for simplification.)
(1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo
each character I send to them.
(2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive
an echo for each character sent.
Part (1) above seems to fit properly. If I send the DO ECHO, the host
happily echos everything back to me. However, part (2) doesn't seems to
always apply -
On varied pieces of equipment, it does what I expect - a DONT/WONT pair
causes the host not to echo anything back. However, whenever I try this
when I'm connected to a BSD machine, the host accepts my DONT ECHO,
replies with WONT ECHO, and then procedes to continue echoing anyways.
What gives? Am I interpreting things wrong? Is this option incorrectly
implemented in some BSD revisions?
--
+----------------------------------------------------------------+
| A sign of mismanagement, over- | Greg Miller |
| complication and overall idiocy: | ..ames!sharkey!ionic!gm |
| | gm@ionic.uucp |
| "Designed By Committee" | |
+----------------------------------------------------------------+conti@ltisun7.epfl.ch (Giovanni Conti) (11/23/90)
In article <gm.3504@ionic.UUCP>, gm@ionic.UUCP (Greg Miller) writes: > > (There's no need to explain the need to respond to a "WILL/WONT" with a > "DO/DONT" rather than the other-way-around; I'm fully aware of that, and > make use of it. I don't include it here for simplification.) > > (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo > each character I send to them. I think there is a need to explain the WILL/WONT mechansim. The ECHO is LOCAL. So if you ask your partner to do echo, he will duplicate his output stream (from him to you) onto his input stream. That means that a UNIX system doing Telnet echo and sending you a "Username:" string will also read the same string in its input stream. So obviously, the UNIX system never does Telnet echo locally. On the other side, you (e.g. the terminal) are expected to do some local echo of the keyboard input to the screen (echo your input stream to your output stream). If the system does not want you to do that (e.g. when you type the password), it tells you DONT ECHO, which means "Just send me the characters, I will echo back what I think is reasonable". In that case you do not echo the characters locally on your screen. If you ask the host to do ECHO, and assuming he answers WILL ECHO, that means that when he sends you the string "Username:", telnet echoes him a copy as if you've typed "Username:", leading to wrong behaviours. So don't tell the host to do local echo (local to him) if you are a Telnet Client (or unless you know exactly what you're doing). > > (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive > an echo for each character sent. > So this is wrong. But fortunately, according to your request, the BSD host will not read in its input stream all the characters it sent to you. > Part (1) above seems to fit properly. If I send the DO ECHO, the host > happily echos everything back to me. However, part (2) doesn't seems to > always apply - > The fact of echoing everything back to you means: a) that you did not do local echo in the beginning (unless you received all duplicated characters. So there is an error in your Telnet implementation. b) That the Application echo (e.g. the login deamon on a host) has NOTHING to do with your Telnet echo commands. In fact, the application running on top of telnet (e.g. csh) may echo back things, asking you first NOT to do local echo (so you receive a DONT ECHO from the host). Good luck Giovanni Conti Ecole Polytechnique Federale de Lausanne Laboratoire de Teleinformatique EL-Ecublens CH-1015 Lausanne Switzerland Tel : +41 21 693.29.07 FAX : +41 21 693.46.60 E-mail: conti@ltisun.epfl.ch
dab@BERSERKLY.CRAY.COM (David Borman) (11/27/90)
Before things get out of hand, here is some clarification about the telnet ECHO option. The response to the original question is WRONG!!!. From the original questions: > (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo > each character I send to them. This is exactly correct. > (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive > an echo for each character sent. This is also exactly correct. > Part (1) above seems to fit properly. If I send the DO ECHO, the host > happily echos everything back to me. However, part (2) doesn't seems to > always apply - The only reason that either part (1) or part (2) would not work is due to a broken telnet implementation. Now for some clarification about how the telnet ECHO option shoule be used, in the typical "terminal/client to server". First, there are two pieces of information involved: 1) should the users typed data be echoed to the users screen, and 2) is the server WILL ECHO or WONT ECHO. 1) The connection should NEVER be WILL ECHO in both directions. In the typical terminal/client to server application, there is no need for the client to ever be WILL ECHO. 2) When the server is WONT ECHO, then if the users typed data is to be echoed to the users screen, then that has to be done locally on the server side. 3) If the server is WILL ECHO, then the telnet client should not do any local echo of the users typed data, as the remote server will be echoing any data that needs to be echoed; if the client continues to do local echo, the user would see double echo of the typed characters. 4) When the server is WILL ECHO, it is not required to echo the incoming data verbatim, it may chose to not echo some of the data (like passwords) or may chose to echo data in a different format (like control characters as a two character sequence, e.g. "^A"). These diagrams represent the typical UNIX environment; your milage may vary. The "(tty)" and "CLIENT" boxes, and the "SERVER", "(pty)" and "Application" boxes may be combined as appropriatly for different systems, but the basic concept remains the same. The double-dashed line is the path where both normal data and echoed data is flowing. It is assumed that the users data is to be echoed. Server WONT ECHO: (tty) CLIENT SERVER (pty) Application +-----+------+ +------+-----+---------+ | | | | | | | terminal ->|--+->|----->|---->|----->|---->|->(read) | | | | | | | | | | | | | | | | | | V | | | | | | screen <=|==+--|<-----|<----|<-----|<----|<-(write)| | | | | | | | +-----+------+ +------+-----+---------+ Server WILL ECHO: (tty) CLIENT SERVER (pty) Application +-----+------+ +------+-----+---------+ | | | | | | | terminal ->|---->|----->|---->|----->|--+->|->(read) | | | | | | | | | | | | | | | | | | | | | | V | | screen <=|=====|<=====|<====|<=====|==+--|<-(write)| | | | | | | | +-----+------+ +------+-----+---------+ If the client was ever WILL ECHO (sever WONT ECHO), you would have something like: (tty) CLIENT SERVER (pty) Application +-----+------+ +------+-----+---------+ | | | | | | | terminal ->|---->|---+=>|====>|=====>|====>|=>(read) | | | ^ | | | | | | | | | | | | | | | | | | | | | screen <-|-----|<--+--|<----|<-----|-----|<-(write)| | | | | | | | +-----+------+ +------+-----+---------+ which would not be very useful. -David Borman, Chair of the IETF Telnet Working Group dab@cray.com
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (11/27/90)
In article <1191@disuns2.epfl.ch> conti@ltisun7.epfl.ch (Giovanni Conti) writes: >I think there is a need to explain the WILL/WONT mechansim. Yes, someone should explain it to you, since not only don't you understand it, but worse, you don't know that you don't understand it and you are spreading misinformation. Please don't do so in the future. There are enough people around here who have written Telnet software -- I've written several servers and clients for different operating systems, going back to 1976 -- who can answer Telnet protocol questions correctly. The Telnet ECHO option, in a server/client environment, refers to echoing done by the server of data from the client back to the client. In other words, it is only meaningful for a client to send: IAC DO ECHO (requesting/confirming that the server echo) IAC DONT ECHO (demanding/confirming that the server not echo) and for a server to send: IAC WILL ECHO (requesting/confirming that it will echo) IAC WONT ECHO (refusing/confirming that it will not echo) In a bilateral Telnet (e.g. station-to-station) where there is no clear server or client than it may be reasonable for echoing in both directions. >The ECHO is LOCAL. So if you ask your partner to do echo, >he will duplicate his output stream (from him to you) onto >his input stream. Totally wrong. The Telnet ECHO option controls remote echoing; local echoing is only implicit. An echo is never "a duplication by an agent of his output stream onto his input stream." An echo is a "duplication by an agent of his input stream onto his output stream." >If you ask the host to do ECHO, and assuming he answers WILL ECHO, >that means that when he sends you the string "Username:", telnet echoes >him a copy as if you've typed "Username:", leading to wrong behaviours. No, no, no, 1000 times no. That is what "IAC WILL ECHO" from the Telnet client means. I didn't see the original question, but it seems that you have sent some poor guy on a wild goose chase. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ FAX: (206) 543-3909 "Iie, boku ha nihonjin." / | \ | |__| / \ / \MRC@CAC.Washington.EDU "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
gm@ionic.UUCP (Greg Miller) (11/27/90)
In article <1191@disuns2.epfl.ch>, conti@ltisun7.epfl.ch (Giovanni Conti) writes: > In article <gm.3504@ionic.UUCP>, gm@ionic.UUCP (Greg Miller) writes: {Parts of my previous question deleted} > > I think there is a need to explain the WILL/WONT mechansim. > The ECHO is LOCAL. So if you ask your partner to do echo, > he will duplicate his output stream (from him to you) onto > his input stream. That means that a UNIX system doing Telnet echo > and sending you a "Username:" string will also read the same string > in its input stream. So obviously, the UNIX system never does Telnet > echo locally. On the other side, you (e.g. the terminal) are expected > to do some local echo of the keyboard input to the screen (echo > your input stream to your output stream). If the system does not > want you to do that (e.g. when you type the password), it tells > you DONT ECHO, which means "Just send me the characters, I will echo > back what I think is reasonable". In that case you do not > echo the characters locally on your screen. > > If you ask the host to do ECHO, and assuming he answers WILL ECHO, > that means that when he sends you the string "Username:", telnet echoes > him a copy as if you've typed "Username:", leading to wrong behaviours. > > So don't tell the host to do local echo (local to him) if you are > a Telnet Client (or unless you know exactly what you're doing). Here's the important piece of RFC 857: - cut - 2. Command Meanings IAC WILL ECHO The sender of this command REQUESTS to begin, or confirms that it will now begin, echoing data characters it receives over the TELNET connection back to the sender of the data characters. IAC WON'T ECHO The sender of this command DEMANDS to stop, or refuses to start, echoing the data characters it receives over the TELNET connection back to the sender of the data characters. IAC DO ECHO 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. IAC DON'T ECHO The sender of this command DEMANDS the receiver of this command stop, or not start, echoing data characters it receives over the TELNET connection. - cut - Calling my system the "client", the remote system (a BSD system) the "host", and using the above chunk of the RFC: My sending a DO ECHO should request that the host begin echoing all data characters it receives back to the sender (me). A reply of WILL ECHO should stand as a confirmation that the host will indeed begin echoing all data characters back to the sender. I don't see how this creates the situation you described. You claimed that this would cause the host to echo it's output back into it's input path (which infers an infinite loop). That's the exact opposite of what I interpret the above as stating. > > > > > (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive > > an echo for each character sent. > > > > So this is wrong. But fortunately, according to your request, the BSD host > will not read in its input stream all the characters it sent to you. See above. > > > Part (1) above seems to fit properly. If I send the DO ECHO, the host > > happily echos everything back to me. However, part (2) doesn't seems to > > always apply - > > > > The fact of echoing everything back to you means: > > a) that you did not do local echo in the beginning (unless you received > all duplicated characters. So there is an error in your Telnet > implementation. > > b) That the Application echo (e.g. the login deamon on a host) has > NOTHING to do with your Telnet echo commands. In fact, the application > running on top of telnet (e.g. csh) may echo back things, asking > you first NOT to do local echo (so you receive a DONT ECHO from the host). > > Good luck Thanks. I'm going to need it. > > Giovanni Conti > Ecole Polytechnique Federale de Lausanne > Laboratoire de Teleinformatique > EL-Ecublens > CH-1015 Lausanne > Switzerland > Tel : +41 21 693.29.07 > FAX : +41 21 693.46.60 > E-mail: conti@ltisun.epfl.ch One last comment - are you by chance reading the RFC from the perspective of the host, rather than the client? That would lead to the interpretation that you gave. Thanks. -- +----------------------------------------------------------------+ | A sign of mismanagement, over- | Greg Miller | | complication and overall idiocy: | ..ames!sharkey!ionic!gm | | | gm@ionic.uucp | | "Designed By Committee" | | +----------------------------------------------------------------+
conti@ltisun.epfl.ch (Giovanni Conti) (11/27/90)
In article <gm.3508@ionic.UUCP> gm@ionic.UUCP (Greg Miller) writes: > > > One last comment - are you by chance reading the RFC from the perspective >of the host, rather than the client? That would lead to the interpretation >that you gave. 1) The first time I read it (about 2 years ago) I misunderstood it, merely triggered by questions like yours. I then got the correct understanding of it by looking at our local net. However, when I read your mail, I remembered my first understanding (which was wrong). So I apologize for leading to confusion. 2) Thanks to Mark ("Gaijin") Crispin for correcting me. Giovanni Conti Ecole Polytechnique Federale de Lausanne Laboratoire de Teleinformatique EL-Ecublens CH-1015 Lausanne Switzerland Tel : +41 21 693.29.07 FAX : +41 21 693.46.60 E-mail: conti@ltisun.epfl.ch
kre@cs.mu.OZ.AU (Robert Elz) (11/29/90)
In article <gm.3504@ionic.UUCP>, gm@ionic.UUCP (Greg Miller) writes: > However, whenever I try this > when I'm connected to a BSD machine, the host accepts my DONT ECHO, > replies with WONT ECHO, and then procedes to continue echoing anyways. There's been a lot of discussion on the nature of DO ECHO / DONT ECHO, etc, in response to this, but I don't recall much discussion on the actual problem being reported. I believe that BSD systems get "DONT ECHO" right, when you ask for them to not echo, they don't. But note that "DONT ECHO" is not "DONT OUTPUT" - ie: you still get any output that processes want to generate (of course). The perceived problem is really that some of what seems to be echo is really program output - it just appears as if it may be echo. In particular, the "login" program outputs the login name that you enter (character by character). This is not "echo", its program output, and as such, the telnet echo options have nothing to do with it whatever. kre