I am using a vintage serial terminal connected to a linux box via a USB to RS232 serial null modem cable. The terminal uses XON/XOFF flow control to avoid overflowing the buffer. The terminal works great for activities running on the linux box. However, if I SSH to my server, VMs, or even localhost, I begin having buffer overflows. It looks like SSH is interfering with the XON/XOFF flow control. Any ideas where I may be going wrong here?

Additional Details:
1) Terminal connected to computer via StarTech FTDI USB to RS232 Serial Null Modem Adapter Cable
2) Serial interface through getty on ttyUSB0, 19200 baud, vt100
3) VT100 is setup also to 19200 for both transmit and receive

  • Well, what are the settings on your other devices in regards to connecting via serial? What application are you using to interface with the serial terminal? Are you connecting via ssh to other resources after you connect to your Linux box via serial? What model/make of serial adapter are you using? – Richie086 Jul 4 '16 at 21:54
  • 1
    @Richie086, Thanks, I updated with additional info. The connection is fine when working with programs on the connected computer. If I ssh to another machine (from the connected computer), it appears the buffer overflows and I get incomplete output on the "dumb" terminal. – SpaceNut Jul 4 '16 at 22:25
  • Have you tried setting the baud rate lower than 19200k? – Richie086 Jul 4 '16 at 22:27
  • I tried at 9600 baud and saw the same behavior. – SpaceNut Jul 4 '16 at 23:17
  • In the telecommunications industry I have dealt with a lot of "dumb" terminals, a common cause of these "buffer overflows" is actually that the screen just can't keep up with the current "Scrolling" method, look in the terminal setup for Scroll Method or Scroll Control, and make sure it is set for Jump (or possibly Smooth-8). Also, see if you can change your flow control on your USB adapter to Hardware or RTS/CTS if your terminal supports it, it is much smoother and more responsive than XON/XOFF – acejavelin Jul 5 '16 at 0:56

ssh in its normal interactive-session mode forwards all characters (except its escape, usually ~) to the remote host, including ^S ^Q. (Anything at the far end of a SSH/TCP/IP connection is 'remote' for this purpose, even localhost/loopback or virtual-LAN.) If you have a 'long' (propagation delay) and/or 'fat' (bandwidth) pipe -- and loopback is definitely fat -- the amount of data that can be in-flight to you before the remote host receives and acts on ^S is probably more than a VT100 can buffer, since it was designed back in the days when connection was an actual piece of wire less than 50' for RS-232, or a direct-modulation one-bit-at-a-time modem like 103 or 212A.

If you use ssh with arguments to run a command on the remote host (not an interactive session) then the terminal handling (and ^S ^Q) remains in the local OS, which should respond fast enough. Obviously this constrains the interaction you can do with the remote host(s). By default it also does SSH overhead (keyexchange and authentication) for each command, which can be costlier and slower, but with non-ancient versions you can set up a master process with -M which shares the transport (and transport setup cost) over multiple worker processes.

The only other solution I see is to not run remote things that produce too much output too fast; for example, pipe things into more or less or similar, maybe even with LINES set to less than 24. Or write large output to a temp file and browse it with vi or similar.

|improve this answer|||||
  • dave_thompson_085 Thank you for setting me straight here. I guess I really underestimated the latency of the network in comparison to the local connection. After @Richie086 question on lower baud rate and your answer, I lowering to 4800 and have very functional results over ssh. I dug a bit more into the VT100 manual and found the input buffer is 128 chars and the XOFF is triggered 73 chars before overflow occurs. At 19200, that gives only 38ms to respond before overflow. Lowering to 4800 gives 152 ms. The joys of retro-computing! Makes you appreciate how far we have come. Thanks guys! – SpaceNut Jul 6 '16 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.