what hardwares does conserver support?

[ On Tuesday, January 22, 2002 at 15:51:21 (-0800), David Harris wrote: ]
> Subject: Re: what hardwares does conserver support?
>
>   I've tested a bunch of terminal/console server devices with
> Conserver. We've been making an effort to identify those
> devices which will only send BREAK when you want to send it,
> and not any other time. (This is important in Sun environments
> using the serial console for remote console access...)

You are fighting against the laws of physics.

You cannot easily avoid having a server detect a break on its console
serial port when the attached device is power cycled, at least not
without making changes to the default circuitry on the host system side
of things.  Cables and connectors will inevitably interfere with your
results except under "ideal conditions".

>   However, you can see what we've found about a number of
> different console servers on the page
> 
>        http://www.conserver.com/consoles/breakinfo.html

This is all very interesting, but potentially very misleading.  Poor
cables, or connectors, could influence the results, as will variations
in the components used in the host system's console serial port, and
even the jumper settings configuring the port.

The only correct and certain solution is hinted to in the last part of
this page:

	http://www.conserver.com/consoles/breaktest.html

and also well described in detail on this mostly correct page:

	http://www.cisco.com/warp/public/770/fn-tsbreak.html

The correct solution is to modify the console serial port on the host
system such that the system itself will supply a data signal in the
absense of a signal from the attached terminal or terminal server, while
at the same time not preventing the terminal server from generating a
real BREAK signal on demand.  One way of doing this is to putting an
approximately 4.7K Ohm resistor between pin 3 and pin 25 (which has -5v
on most Sun systems) on the host end when connecting to a Sun SPARC
host.  This should have the effect of stifling any appearance of a BREAK
signal when the console server machine is either disconnected or power
cycled.  However so long as the terminal server can still send data it
should also still be able to send an intentional BREAK signal as well.
(contrary to the incorrect information on the Cisco page -- obviously if
the resistor held the Rx pin at the mark level permanently then no data
could be sent at all to the port, and similarly if the terminal server
can still toggle the line levels to send data signals then it can
equally well hold the line at the space level for the requisite time to
generate an intentional BREAK signal).

The reason this isn't always reliable for everyone is because depending
on the exact design of the host system's serial console port, the
voltages may vary.  This web page talks about some of the different Sun
systems which have jumper options to switch the port from RS-232
(+/-12vdc signalling) to RS-423 (+/-5vdc signalling):

	http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html

For true RS-232 ports you might sometimes need to hold the Rx pin closer
to -12vdc than -5vdc (while at the same time not preventing the terminal
server from driving the line to +12vdc to send data or a real BREAK).

I have in the past seen a more reliable circuit with a zener diode, but
once you get the right values for your equipment all should work fine.

The other solution is of course to just use a reliable enough terminal
server and never power cycle it, and also of course never disconnect the
console cable on a server that's in production (schedule downtime
first!).  On my home network I use a DECserver on a DEChub500 with
redundant power supplies.  :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>