#941443 openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally

Package:
openssh-client
Source:
openssh
Description:
secure shell (SSH) client, for secure access to remote machines
Submitter:
John Goerzen
Date:
2023-10-12 17:36:19 UTC
Severity:
important
Tags:
#941443#5
Date:
2019-09-30 15:55:13 UTC
From:
To:
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 tiny, 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?

Thanks,

John

#941443#10
Date:
2019-09-30 17:01:27 UTC
From:
To:
Hi Colin,

That makes sense.  I created the report here:

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

- John

#941443#17
Date:
2019-09-30 16:39:06 UTC
From:
To:
[...]

Hi,

I think this needs to be forwarded upstream.  I'm often happy to do that
on people's behalf when I understand a bug well and/or can reproduce it,
but in this case neither of those things is true.  I also suspect that
working out the best fix is going to involve some back-and-forth between
you and upstream, and I'm going to add very little to that process other
than being a rather slow proxy.

Would you consider filing this directly upstream
(https://bugzilla.mindrot.org/)?  I know it's another account to create,
but I think it would work better.

Thanks,