Re: Odd ctrl-s problem.

Many thanks for your replies,

I still haven't got to the bottom of what actually caused it, but, it
seems odd if was the terminal server. Its a reasonably recent event that
conserver went live on these machines - and in the past, the terminal
servers didn't have a connection to them from the network, so, all the
serial traffic was silently thrown away. This is what I was expecting to
happen during the conserver restart window. (People used to ssh to the
terminal server only when they needed the console)

However, I think i'll change the the idlestring to contain ^q - so in
the event of a restart causing it again, at least after 5 minutes of
inactivity, conserver would sent a ctrl-q to it again. (Assuming I can
get it to do this?)

Cheers
Pete

On Wed, Feb 06, 2008 at 12:42:25PM -0500, Greg A. Woods wrote:
> 
> 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>
> 
> 
> 
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users