[Bug 3075] New: Causes terminal corruption by disabling XON/XOFF unconditionally

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3075

            Bug ID: 3075
           Summary: Causes terminal corruption by disabling XON/XOFF
                    unconditionally
           Product: Portable OpenSSH
           Version: 7.9p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: jgoerzen at complete.org

Hello,

I am using an original DEC vt420 serial terminal connected to a Debian
box.  As with many such terminals, it:

1) Is incapable of consistently processing incoming data, particularly
if it contains escape sequences, at line rate if the line rate is
above 4800bps (though it supports line rates up to 38400bps);

2) Supports only XON/XOFF flow control.

I observed issues that were clearly related to flow control with
sshing from it to other systems, although it was working fine
locally.  I narrowed it down to this code in
sshtty.c:enter_raw_mode():

        tio.c_iflag &= ~(ISTRIP | INLCR | IGNCR | ICRNL | IXON | IXANY
| IXOFF);

in other words, it unconditionally disables XON/XOFF handling on the
local machine.

You might be asking at this point: well, couldn't the remote handle
it?  And the answer is no, for several reasons:

1) The internal buffer on this terminal is 254 bytes, far less than
even
the TCP packet size.  It is quite possible -- likely, even -- that a
large screen update already caused a packet to be transmitted from the
remote end that will overflow the local buffer.

2) The latency in processing could mean that the remote sends enough
text to overflow the terminal's buffer after the terminal sends XOFF.

Other people from around the internet also report this issue.  For
instance:

https://superuser.com/questions/1096862/ssh-and-xon-xoff-software-flow-control

I recognize that there may be reasons to drop IXON and IXOFF by
default, but they are not appropriate for situations in which IXON and
IXOFF are legitimately needed.  Perhaps a configuration option here?

I'm happy to test patches, etc.

Thanks,

John

-- 
You are receiving this mail because:
You are watching the assignee of the bug.