wrk@abvax.icd.ab.com (William R. King) (07/29/87)
Last week I posted a query about CR processing. I was able to telnet
to TWG telnet from a 4.3 BSD system only if I was connected on a
direct line. I was not able to connect when I was logged into the BSD
system via a Bridge CS/1.
The problem stemed from the connection between the Bridge CS/1 and
the BSD 4.3 telnetd. The CS/1 was incorrectly sending \r\n as the
line terminator instead of the correct \r\0 sequence. The BSD telnetd
converted the \r\n sequence into \n and sent that into the pty. The
\n was passed on to TWG telnet which interpeted \n as "delete the
word to the left of the cursor". So much for logging in.
I have since obtained a new release of Bridge CS/1 software (version
13000) which fixes the problem. They now offer the option (per port)
of sending \r\n or \r\0 as the line terminator.
I thank the many people who took time to respond. It made life
much simpler.
Bill King
Allen-Bradley Company, Inc.
...!{decvax,pyramid}!abic!wrksrg@quick.UUCP (Spencer Garrett) (08/09/87)
In article <27@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) writes: > Last week I posted a query about CR processing. > The problem stemed from the connection between the Bridge CS/1 and > the BSD 4.3 telnetd. The CS/1 was incorrectly sending \r\n as the > line terminator instead of the correct \r\0 sequence. The BSD telnetd > converted the \r\n sequence into \n and sent that into the pty. The > \n was passed on to TWG telnet which interpeted \n as "delete the > word to the left of the cursor". So much for logging in. > > I have since obtained a new release of Bridge CS/1 software (version > 13000) which fixes the problem. They now offer the option (per port) > of sending \r\n or \r\0 as the line terminator. But this is incorrect! The Bridge box SHOULD be sending \r\n when you hit <RETURN> or <ENTER> or whatever it's labelled on your keyboard. This is the TELNET "end of line" indicator. Telnetd correctly converts this to \n which is the equivalent sequence in a UNIX context. The problem appears to be the Berkeley telnet program (as opposed to the daemon) which is failing to convert \n to \n\r like it should, or perhaps TWG telnet is failing to accept \r\n as the TELNET eol. The sequence \r\0 is a "bare" carriage return which should get you to the beginning of the line WITHOUT ending the line. This is the behaviour you would get under UNIX with CRMOD turned off. The proper sequence should be: You hit <RETURN> The Bridge box sends \r\n telnetd converts \r\n to \n and feeds it to the pty telnet reads \n from its tty (pseudo-tty, but it shouldn't matter) telnet sends \r\n through its tcp stream to the vax the vax should convert \r\n to whatever it wants for EOL Making the Bridge box precompensate for a bug elsewhere by sending an incorrect sequence is not good polican
sid@llama.rtech.UUCP (Sid Shapiro) (08/10/87)
This is going back a bit, and may not even be the same thing, but when I switched a system to 4.3, we could no longer get a <CR> characters into emacs (or vi for that matter, but vi didn't really care too much). If I remember correctly, the 4.3 telnetd was "smarter" - it could map <CR>s to <NL>s if you wanted it to (default behavior). This screwed up the Bridge boxes, cause the bridge telnet client didn't have a command to reset the telnetd to go back to the less smart behavior. I had to hack telnetd to turn off the mapping.
barmar@think.COM (Barry Margolin) (08/11/87)
In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes: > You hit <RETURN> > The Bridge box sends \r\n You said this twice in your message without justifying it. The key is labeled RETURN, which is generally taken to be a synonym for CR. The TELNET spec says that CR should be represented in NETASCII as CRNUL. Why should the Bridge box assume that CR is NEWLINE? > telnetd converts \r\n to \n and feeds it to the pty > telnet reads \n from its tty (pseudo-tty, but it shouldn't matter) > telnet sends \r\n through its tcp stream to the vax > the vax should convert \r\n to whatever it wants for EOL What if the program on the VAX wants to see the raw characters that the user typed, which happens in programs such as EMACS? This means that if the user types CR it will get translated into the VAX's EOL sequence, and the program may not see the CR that the user typed. Your scenario only works if the remote system is in line-at-a-time mode. The reason for all the confusion that the TELNET spec has caused is that NETASCII is used for more than terminal emulation. It is used in FTP, for example, to support the control connection and text-mode file transfers. In these cases, things like End-of-Line have much more obvious meaning, or at least the need for a standard representation is obvious (some systems use a character sequence to indicate newline, others use a record structure). In terminal emulation, whether the RETURN key indicates End-of-Line is totally context dependent. In EMACS I can map any key to any operation, and I don't want the network to transform my keyboard for me. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
JTW@XX.LCS.MIT.EDU (John T. Wroclawski) (08/11/87)
Summary: Chuck Hedrick's recent letter hit the nail on the head.
From: barmar@think.com (Barry Margolin)
Subject: Re: telnet CR processing, bridge comm servers and TWG telnet
In article <109@quick.UUCP> srg@quick.UUCP (Spencer Garrett) writes:
> You hit <RETURN>
> The Bridge box sends \r\n
You said this twice in your message without justifying it. The key is
labeled RETURN, which is generally taken to be a synonym for CR. The
TELNET spec says that CR should be represented in NETASCII as CRNUL.
Why should the Bridge box assume that CR is NEWLINE?
Because it is the character most often sent by the key that most
people using terminals likely to be hooked to Bridge boxes use for
EOL, and you have to have some way to send a NEWLINE.
However, it doesn't really matter -what- the bridge box sends. The only
thing that matters is that the terminal<->NETASCII<->machine transformation
be invisible.
For unix-like systems this is easily achieved by having the server telnet
translate incoming CR-LF and CR-NUL to CR, and incoming LF to LF. This
result is then stuffed into the PTY, where normal terminal processing
(CRMOD) takes care of the rest, including your objection below. (Which
-is- a problem if CR-LF translates to LF, as Spencer suggested.)
> telnetd converts \r\n to \n and feeds it to the pty
> telnet reads \n from its tty (pseudo-tty, but it shouldn't matter)
> telnet sends \r\n through its tcp stream to the vax
> the vax should convert \r\n to whatever it wants for EOL
What if the program on the VAX wants to see the raw characters that
the user typed, which happens in programs such as EMACS?...
-------chris@GYRE.UMD.EDU (Chris Torek) (08/11/87)
Why are things always more complicated than they need to be? Let us see what happens if we break this down carefully. First, telnet seems to assume that there is a User on a Terminal (possibly a Printing Terminal) who is connected, either directly or via modem, to a Host. This Host is connected to another Host via the Internet. Let us name these hosts to avoid confusion: the first will be Tachost, the second Usefulhost. Now as to cases: Usefulhost can try to print a line to User. To do so, it sends characters to Tachost, and then it sends an End Of Line. What is this End Of Line? It seems fairly well agreed that it is a CR plus an LF. To print this, should Usefulhost send <CR><NUL><LF> or just <CR><LF>? Either should work, but the latter should be preferred. Tachost must arrange for either to produce the appropriate printhead or cursor motion. Usefulhost can also try to do fancy printhead motion (if our User is on a Printing Terminal), namely, `go back to the beginning of the line and get ready to overstrike' or `go down one line'; for these it should send <CR><NUL> and <LF> respectively. It is obvious that <CR><NUL><LF> will move the printhead to the beginning of a new line, though possibly inefficiently, which is why we say <CR><LF> is preferred. Now on the other hand, User may be trying to send a line to Usefulhost. Here the situation is murkier. User pushes keys for characters; upon these we agree: they are just plain ASCII. (Let us not consider binary EBCDIC, please!) But then User pushes a key marked ENTER. Or is it marked RETURN? Maybe LINE FEED? Or perhaps even NEWLINE. Just what key *is* this, anyway? I cannot speak for everyone, but all *my* terminals have a great big key marked RETURN. It sends <CR>. They also have an ordinary sized key marked LINE FEED, and it sends <LF>. But apparently there is at least one Tachost that has different terminals, with keys marked ENTER that send <CR><LF>. The clear, obvious solution is to have Tachost send <CR> when a User types RETURN, <LF> when a User types LINE FEED, and <CR> when a user pushes an ENTER key that sends <CR><LF>. Terminals with just one big ENTER key thus cannot send <LF>. Well, that is natural since they have no key for it. As long as the terminal has separate keys, though, it should be Tachost's job to send to Usefulhost exactly that key which was typed. Alas, telnet does not use the clear, obvious solution. It imposes on a User the very same protocol used for making a Terminal or Printer work. This is odd, for Users are not at all like Terminals and Printers, but we are stuck with it. At least it is symmetric---or is it? If Tachost can easily tell which key User typed, *I* say it should send that very key to Usefulhost. So (since we have this extra protocol in the way) let us define that Tachost is to send either <CR><NUL> or <CR><LF> (it should not matter which) when User types RETURN, and <LF> when User types LINE FEED. If User types ENTER and Tachost cannot tell which was meant, let it again send either <CR><NUL> or <CR><LF>. Note that in the Tachost->Usefulhost path, <CR><LF> means RETURN, while on the Usefulhost->Tachost path, <CR><LF> means NEW LINE. This is--- alas!---not symmetric, but is clearly necessary since many Tachosts already send <CR><LF> when a User hits RETURN. Note also that <CR><NUL> is useless, since it means the same thing as <CR><LF>; nonetheless, it must be retained for compatibility, since other Tachosts already send <CR><NUL> when a User hits RETURN. Summary: End host should send <CR><LF> for NEW LINE, <CR><NUL> for cursor-to-beginning-of-line, <LF> for cursor-down-without-return. Intermediate host should send <CR><LF> or <CR><NUL> for RETURN, <LF> for LINE FEED. Neither host should ever send <CR> without immediately sending either <LF> or <NUL>. Chris
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (08/12/87)
The main problem we've found with the blasted BRIDGE boxes is that they insist on negotiating BINARY mode when you open the connection. This screws up all kinds of things. You really want the NVT mapping when dealing with dissimilar machine/terminal types. -Ron