From: towen@relay.nswc.navy.mil (Thomas F. Owen)
Subject: Stairstep Problem with telnet to CRAY
Organization: Code E402, Naval Surface Warfare Center
Date: Sat, 10 Oct 1992 14:05:57 GMT


We have CRAY YMP-2E systems using UNOCOS 6.1.6 and we are experiencing
problems similar to those reported to Cray and outlined below.  However,
our problems are NOT limited to ksh since mailx will exhibit the same
phenomenon when the ~h is attempted.  Cray's response is that the Berkeley
telnet is the problem and it must be changed.  My question is does Sun and
other systems based on Berkeley agree with Cray's diagnosis and if so, is
there a workaround or permanent fix available or in progress?

Problems reported to CRAY and CRAY's responses:

Description:
When I telnet to the CRAY from my local SUN, and use ksh(1) as
interactive shell on the CRAY, the screen output will be garbled
intermittendly: Line break are interpreded as newlines instead of
newlines and carriage return. E. g:

     these
          are
             three
                  lines

instead of:

     these
     are
     three
     lines

The symptom is more likely to occur with longer printouts (e. g.
'cat /etc/passwd') than with short ones, but sometimes it even
happens with short outputs. It makes no difference if the output
comes from a ksh builtin or from a command that was executed by ksh.
Frequently only the last couple of lines from a longer printout is
garbled.

The symptom does NOT occur, if you either

         use rlogin instead of telnet, or
         use a shell different from ksh, or
         rlogin to the cray, and then 'telnet localhost'.


Cray Reply:
This is not a problem with any of the software on the Cray computer.  It is a
problem with the telnet on the front end machine.  The telnet that Sun supplies
is based on a version of telnet from Berkeley that is several years old.
When running ksh with command line editing enabled, ksh switches the state
of the connection into single character mode when at the shell prompt.  When
the command has been typed, ksh switches back into line mode and executes
the command.  When the command completes, ksh goes back into single character
mode.

The client telnet reads the data from the network, parses it looking for
telnet commands, copying the user data into an output buffer.  The problem
is that when the client telnet discovers the telnet command to switch modes,
it needs to write out the data in its output buffer before actually switching
modes.  The Sun telnet is not doing this, it switchs modes and THEN writes out
the buffer.  When it is in single character mode, it does not do NL -> CR/NL
mapping, so that is why the last part of the data is missing the carriage
returns.


KSH GARBLES SCREEN WHEN DOING AN LS -L OR CAT'ING A FILE

Description:
We are up on Unicos 6.1.5 now. Sometimes quite freguently when using
commands ls -l  and cat'ing a file, etc. the kornshell garbles the
screen with the information. ex: ls -l

-rw-------   1 morris   systems     1546 Sep 26 14:04 techop.notes
-rw-r-----   1 morris   systems     2646 Dec 17  1990 tel.info
-rw-r-----   1 morris   systems     1259 Dec 17  1990 telnet.39518
drwx------   2 morris   systems      384 Oct 17  1990 test/
-rw-r-----   1 morris   systems     4708 Oct  1 15:24 title61.o
-rw-------   1 morris   systems        2 Jan 24  1991 to_do.list
oot     root      409565 Aug  6 15:29 tookoff*                  mrwx------   1 r
  1216 Jul 19 14:23 tp.trace                  -rw-r-----   1 morris   systems
9 tree                      mrw-------   1 morris   systems    32615 Aug 30 09:2
      drwx------   3 morris   systems      640 May 17 15:44 util/
morris   systems    16838 Oct  9 09:17 war.1008                  -rw-r-----   1

    334 Oct 16 16:41 x.48456
4 xx                        -rw-------   1 morris   systems      788 Oct  7 13:2
    /csystems/morris-=>

This is causing quite a problem with the users.



Cray Reply:
This is not a problem with any of the software on the Cray computer.  It is a
problem with the telnet on the front end machine.  The telnet that Sun supplies
is based on a version of telnet from Berkeley that is several years old.
When running ksh with command line editing enabled, ksh switches the state
of the connection into single character mode when at the shell prompt.  When
the command has been typed, ksh switches back into line mode and executes
the command.  When the command completes, ksh goes back into single character
mode.

The client telnet reads the data from the network, parses it looking for
telnet commands, copying the user data into an output buffer.  The problem
is that when the client telnet discovers the telnet command to switch modes,
it needs to write out the data in its output buffer before actually switching
modes.  The Sun telnet is not doing this, it switchs modes and THEN writes out
the buffer.  When it is in single character mode, it does not do NL -> CR/NL
mapping, so that is why the last part of the data is missing the carriage
returns.

In order to resolve this problem, a fix must be obtained from the front end
vendor.


Additional information provided by Cray includes:

Csh and sh are line oriented shells.  As a result, telnetd does not
switch from character mode to line mode when sending large oputput
back to the user's terminal.  Since telnetd does not switch modes
when the user is executing these shells, this problem will never
occur.

On the other hand, ksh is a character oriented shell.  As a result,
when telnetd is receiving input from the user, it is in character
mode.  When output is to be sent back to the front-end, telnetd
switches to line mode for performance reasons.  Once the output is
finished being sent, telentd must change the connection back to
character mode.  Since this switching can occur while output is
still being received by the front-end, it is responsible to make
sure the output buffer is flushed before switching modes.  The
Cray cannont do anything at this point.

As for other front-ends exhibiting this problem, any front-end
version of telnet which is based on the older Berkeley releases
will have this problem (NOT just Sun's).

===================================================================
Thomas F. Owen (towen@relay.nswc.navy.mil)
Work: (703) 663-7614
Paper Mail: NAVSWC, Code E402, Dahlgren VA 22448



Newsgroups: comp.sys.sun.admin,comp.sys.sun.hardware