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@mindrot.org
Reporter: jgoerzen@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
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@mindrot.org
Reporter: jgoerzen@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs