[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Re: Odd ctrl-s problem.

Greg A. Woods woods@weird.com
Wed, 6 Feb 2008 09:42:25 -0800 (PST)

On 6-Feb-08, at 11:31 AM, Brodie, Kent wrote:

Well, it's been a long while since I've had to mess with older terminal
servers, but I seem to recall that some flavors of decservers for
example allowed you to control the pass-through of various control
characters to the port. Specifically, you could control whether things
like BREAK, control-x, control-s, etc got passed through or trapped.

The problem here is definitely not with pass-through of control characters.

It's more to do with the terminal server generating control servers in its own attempt to control the data flowing from the attached device.

Disabling flow control on the port could probably prevent the problem from happening, however then flow control during normal use would then be impossible (pass-through of flow control characters would not have the desired effect -- they don't get passed through SSH and TELNET connections in the way you would want them to be transmitted since buffering in the various network layers would defeat any attempt to use a raw connection).

Proper flow control for interactive use requires that the terminal server perform flow control directly itself (and that the various network layers use whatever mechanisms they have to do flow control properly, right down to the connection to the attached device).

Eg. you want output to stop almost immediately when you hit ^S but you don't want anything to be lost. That means the final output device in front of the user (eg. xterm) interpret the ^S from the user and immediately stop generating output, while at the same time pushing the flow control request back through the various layers (CONSERVER -> SSH -> TELNET -> RS232 or whatever) so that eventually a flow control request reaches the device generating the data in the appropriate form and that all buffered data is preserved in all the various layers in anticipation of the user hitting ^Q to see some more (or that it all be flushed if the user hits ^C or whatever). Note that this may sometimes involve translating the flow control request into a hardware signal change on the RS323 line, such as de- asserting CTS.

Note that flow control may have to work properly though all the layers for more than just interactive uses too. If you don't want data from your attached devices to be lost by conserver in its logs, for example, then you need fully working flow control back through all the layers to the attached devices. If you don't have fully working flow control through all layers then something like a minor network glitch may cause a buffer to fill and all data between that time and the draining of the buffer to be lost forever.

						Greg A. Woods