Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!sharkey!ionic!gm From: gm@ionic.UUCP (Greg Miller) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet's ECHO option Message-ID: Date: 27 Nov 90 04:17:42 GMT References: <1191@disuns2.epfl.ch> Lines: 130 In article <1191@disuns2.epfl.ch>, conti@ltisun7.epfl.ch (Giovanni Conti) writes: > In article , 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" | | +----------------------------------------------------------------+