Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!quick!srg
From: srg@quick.UUCP (Spencer Garrett)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: telnet CR processing, bridge comm servers and TWG telnet
Message-ID: <109@quick.UUCP>
Date: Sat, 8-Aug-87 19:40:44 EDT
Article-I.D.: quick.109
Posted: Sat Aug  8 19:40:44 1987
Date-Received: Sun, 9-Aug-87 23:08:49 EDT
References: <27@abvax.icd.ab.com>
Organization: Quicksilver Engineering, Seattle
Lines: 34
Keywords: telnet TWG Bridge BSD4.3
Summary: Much confusion about line terminators

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