C-Kermit Problem Caused by vt100 XON/XOFF Enabled

Dennis Bednar dennis at rlgvax.UUCP
Thu Jan 9 04:43:07 AEST 1986


[Could someone see that this reaches mod.protocols.kermit? I don't
 know the address of the moderator.]


Quick Overview

VT100 terminal generating XON/XOFF causes Kermit to think extra
command has been typed by person, but actually sent by terminal.
Seen during Kermit data transfer mode (Connected state) when
typing ESCAPE ? to request a help menu.

Details

	While connected, I type ESCAPE ? to get the help menu.
Kermit prints the help menu, then mysteriously printed the status,
as if I had typed S in response to the Command > prompt, but I hadn't.
The problem is that typing control-s into the Command > prompt also
requests a status, *AND MY VT100 HAD XON/XOFF ENABLED*.  The menu
for the connected command caused by vt100 terminal to send XOFF (control-s)
to stop the burst of characters in the menu, then later sent the XON
(control-q) to later resume the output.  Well, the control-s generated
by my terminal accounts for why the the status command mysteriously happened.
I surmise that the control-q was sent as data over the communications line.
I verified this was the problem disabling XON/XOFF on my terminal, then the
ESCAPE ? command then properly waited for terminal input after sending
the Command > prompt. I did not verify with a Line Monitor.

Suggested Solution

	I did not attempt to fix this minor vt100 XON/XOFF problem
in the kermit source code.  Perhaps by temporarily enabling
recognition of XON/XOFF received on the tty side *before* outputting
the help menu, and by restoring it to enable XON/XOFF recognition
*after* outputting the help menu would do the trick.




-- 
Dennis Bednar	Computer Consoles Inc.	Reston VA	703-648-3300
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis
dennis at rlgvax.UUCP



More information about the Comp.unix mailing list