Bug 962 - Data loss in interactive session on slow terminal
Summary: Data loss in interactive session on slow terminal
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 3.9p1
Hardware: All Linux
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-11 04:52 AEDT by Nickolay V. Shmyrev
Modified: 2008-04-04 09:54 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nickolay V. Shmyrev 2004-12-11 04:52:24 AEDT
Hello. I have the following system configuration:

1. Redhat Linux 3.7
2. openssh-3.9p1 with default configuration from RedHat.
3. Old d211 terminal connected to serial port at baud rate 38000

From terminal i do 'ssh somehost'
and then 'ls -la'. Althogh my home directory has many files, the output of ls
has only few lines. Also when I do cat on some large file it is not shown properly.

I've wrote my version of cat which output test file but make delays between
chars. It works slowly but outputs the whole file. So I think the problem is
somewhere in rate of terminal.

Other programs like rsh works fine.
Comment 1 Nickolay V. Shmyrev 2004-12-11 04:59:35 AEDT
Sorry, of course, redhat is 7.3
Comment 2 Darren Tucker 2004-12-11 18:37:11 AEDT
This is unlikely to be an issue with OpenSSH, it it far more likely to be a
problem with either the serial port setup (eg flow control) or some kind of bug
in Linux's tty layer.  I suspect you have compression on, and with compression
ssh can deliver the data faster than either the terminal or tty layer can handle it.

If you redirect the cat to a file, eg:

ssh remoteserver cat /path/to/file > localfile

is the file complete?
Comment 3 Nickolay V. Shmyrev 2004-12-13 01:28:41 AEDT
There is a lot of magic in this behavior. But since this bug is only 
reproduced in ssh, while I am working with other programs a lot and everything 
is fine, I think more about ssh. 
 
Testcases: 
 
1. without ssh 'ls -la' works fine 
2. 'ssh localhost ls -la' works fine 
3. 'ssh localhost' and then 'ls -la>output' works fine, but then 'cat output' 
is broken. 
 
The problem is only reproduced with wide and large files - there should be 
many columns and rows in the text. Small texts are displayed nicely. 
Comment 4 Damien Miller 2004-12-13 10:44:15 AEDT
I am guessing here, but could you try the patch attached to bug #961 ?
Comment 5 Darren Tucker 2004-12-13 11:02:21 AEDT
Do you have flow control enabled on the terminall and serial port?  If not, try
enabling it.
Also, try "stty cols 80" before repeating the tests.
Comment 6 Nickolay V. Shmyrev 2004-12-16 03:39:40 AEDT
I've found the reason of it - to fix this bug one should just remove in sshtty.c
in function enter_raw_mode unset of IXON and IXOFF flags.

What is the reason you unset XON/XOFF on terminal? 

Comment 7 Darren Tucker 2004-12-16 11:50:36 AEDT
I don't know, but it predates the OpenSSH project.  It was in the original SSH
source (although the function used to be in clientloop.c).
Comment 8 Darren Tucker 2005-10-03 18:50:46 AEST
I think I know why this is done: so "chained" connections with ssh -t work, eg:
ssh -tt intermediate.example.com "ssh -tt target.example.com".  If xon/xoff
processing is enabled then then the intermediate ptys will eat the flow control
chars.

Still not sure what to do about it, though.
Comment 9 Damien Miller 2005-11-05 21:56:13 AEDT
I don't think we can change this, for the reason that Darren mentioned. Can you manually use stty(1) to set the xon/xoff flags? (e.g. "stty ixon ixoff")
Comment 10 Damien Miller 2007-06-22 13:58:19 AEST
There isn't much we can do to fix this. As Darren explained in comment #7, deactivation of xon/xoff is the safe default for SSH. I'd suggest that you use the workaround of activating xon/xoff vi stty(8).
Comment 11 Damien Miller 2008-04-04 09:54:59 AEDT
Close resolved bugs after release.