Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!decwrl!decvax!ucbvax!oliver.cray.COM!dab From: dab@oliver.cray.COM (Dave Borman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wollongong telnet and new line processing Message-ID: <8707201919.AA04726@oliver.cray.uucp> Date: Mon, 20-Jul-87 15:19:26 EDT Article-I.D.: oliver.8707201919.AA04726 Posted: Mon Jul 20 15:19:26 1987 Date-Received: Wed, 22-Jul-87 00:44:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 47 In reply to William R. King's message, where he is trying to connect to a VAX/VMS system running Wollongong. He claims that when using telnet from a directly connected terminal on his 4.3BSD VAX things would work, but when he was logged into the VAX via a Bridge cs/1 terminal, all of his \r's were turned into \n, which on VMS thought that meant 'delete a word to the left of the cursor'. Bill changed telnet, and belives that it is a pty problem on the VAX. My guess is that it is either a Bridge or a 4.3 telnetd problem, or mayby even a combination of them. When you run telnet, it defaults to single character input, with remote echo. In this mode, every character that comes in from the terminal/pty is passed straight through. Telnet puts the the terminal/pty into CBREAK mode, with ECHO & CRMOD turned OFF. This means that the terminal driver will do no translation between \r and \n. Hence, if a \n is showing up at the VMS node, it must be coming from before the pty, i.e. either from telnetd or dirctly from the Bridge box. Be aware that between 4.2 and 4.3, changes were made to both telnet and telnetd to deal with the \r/\n issue. 4.2 did not conform to the TELNET spec in this area. A simple test that could be done would be to write a short program that puts the terminal into CBREAK mode, and turns off ECHO and CRMOD, and then just dumps it's input in octal. Run that on the 4.3 VAX when logged in from the Bridge box, and see what it sees when you type \r. Then write a dummy server that does the same thing, run it on some other TCP port, and telnet to that alternate port from the Bridge box (assuming it will let you do that...), and see what it says a \r is. If you get "\n" in the first case, and "\r" or "\r\n" in the second case, the problem is in telnetd. If you get "\n" in both cases, then the problem is in the Bridge box. If the 4.3 telnetd is not in binary mode, then "\r\n" will be translated to "\n". If the bridge box is sending "\r\n" when you type "\r", then the 4.3 telnetd is where the translation is taking place. What should be sent is "\r\0", which is the correct sequence to send according to the TELNET spec. (If the 4.3 telnetd is in BINARY mode, then this translation will not take place.) "\r/\n" means "move the cursor to the begining of the next line", usually tranlated to '\n' on UNIX machines, "\r\0" means do a "carriage return", (octal 015) and a '\n' (not preceeded by '\r') means do a "line feed" (octal 012). I hope I've helped to clarify things, not confuse them even more. -Dave Borman, Cray Research, Inc. dab@umn-rei-uc.arpa