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