Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!rutgers!mtune!codas!novavax!atlas!jjensen
From: jjensen@atlas.UUCP (Jim Jensen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Wollongong telnet and new line processing
Message-ID: <504@atlas.UUCP>
Date: Wed, 22-Jul-87 08:56:37 EDT
Article-I.D.: atlas.504
Posted: Wed Jul 22 08:56:37 1987
Date-Received: Fri, 24-Jul-87 06:43:59 EDT
References: <25@abvax.icd.ab.com>
Organization: Gould CSD, Fort Lauderdale, FL
Lines: 49
Keywords: Wollongong telnet BSD4.3
Summary: BSD 4.3 new line processing and VMS



in article <25@abvax.icd.ab.com>, wrk@abvax.icd.ab.com (William R. King) says:
> 
> I've been tyring to get our BSD 4.3 VAX to talk to a VAX/VMS
> system using Wollongong telnet and have discovered an interesting
> problem. Unix uses \n as the line terminator,
>[deleted about sending a \r to VMS]
> Unix translate the \r into a \n and sends it across the net
> [problems this causes on VMS deleted]
> I've modified telnet to send a \r instead of a \n for the line
> terminator. Although I think this is only a work around.
> 
> I say this because if you are connect to the Unix machine
> via a direct line everything works fine. This problem only
> occurs when you are connected via a pty. We use Bridge
> cs/1 terminal servers almost exclusivly, hence you are always
> connected to a pty and never to a direct line. 
> 

(this is my first posting so I dont know if I am doing this right)

I just finished writing telnet for MPX (Gould's real time OS), and ran into 
the same problem.  The bridge box sends a \r\n which is the specifed in the
telnet rfc as the end of line character. which the unix telnet server turns
into a \n.

on telnet 4.2 the  telnet task, converts this back to \r\n 
which the VMS(or MPX)server converts back to a \r and everything works.

4.3 leaves it as a \n, which seems to me to be a clear violation of the 
protocol.  The rfc SAYS that \r\n is the end of line character, not \n.
Thats what protocols are for; To take care of differences between machines.
When a protocol is not followed problems like this happen.

I asked one of our unix people about it, and he said that  
BSD did it on purpose, and it is in telnet. I was unable to convince
him it was a mistake, so he would not change it.  that is until some people
in our unix group tried to use a bridge box. Thus:

 the latest patch to Gould Unix has a telnetd which has a variable that can be
set called Telnet_with_a_bridge_box(if I remember correctly) that if set fixes 
the problem.

I am not a unix person, so I may have gotten something wrong about unix, but
I don't think so.
                                              Jim Jensen
					      Gould inc. CSD 
					      6901 West Sunrise Boulevard