Subject: Re: help! carriage return problems?

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Nov 1994 21:22:45 -0800

On 30 Nov 1994, Robert Allan Sutton wrote:
> I'd be very interested in hearing if this actually fixes the problem. We have
> noticed the exact same symptoms here on one of our BSDI systems. The problem 
> only occurs from certain Macintosh clients. However, those same clients can
> connect to other systems with no problems, and other machines can connect to
> our BSDI system and run pine (and pico) with no problems. Perhaps someone
> (Mark?) could explain just exactly what it is that is broken in the NeXT
> telnetd and whether the problem has also been seen elesewhere. I looked at 
> file Mark mentions above, however it does not include any explanation or
> source code or I might try to compile it here. If anyone has any insights as
> to what is going on, I would be very appreciative.

Several years ago, a buggy version of the telnet daemon was released on 
BSD systems.  NeXT systems are distributed with version 5.45 of 6/28/90 
which is one of the buggy versions.  By version 5.48 of 3/1/91, this bug 
was fixed.

The bug is that the broken telnetd version converts the Internet newline
sequence CR LF into LF, apparently in a misguided notion of converting it
to UNIX newline.

Because of this UNIX telnetd bug, many Telnet clients do not send Internet
newlines.  They send CR NUL, which is the Telnet protocol command to send
a raw CR.  Other Telnet clients, such as the Mac ones you mention, follow
the spec and send Internet newlines when the user hits return. 

It must be emphasized that there is nothing wrong with the Mac clients; 
they are doing the right thing and it is the UNIX servers that are broken. 
Furthermore, this bug was fixed years ago, so it is only the extreme 
laziness of vendors such as NeXT that this bug still persists.  If your 
UNIX system still has this bug, you might want to ask its vendor what 
other bugs you have due to their callousness.

The telnetd binary that I distribute on the ftp.cac.washington.edu server
comes from netbsd sources on CD-ROM.  The only change which I made to the
source was to insert a workaround to the process group handling, necessary
because NeXT broke the tty driver in 3.1 (still broken in 3.2). 

My recommendation to fix your BSDI system is to get any of the UNIX
CD-ROMs with telnetd sources, and build your own copy of a modern telnetd.