Re: Odd ctrl-s problem.

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
						<woods@weird.com>