Mailing List Archive

On Tue, Jan 22, 2002 at 03:03:20PM -0600, Kailash Kayastha wrote:
> Hello:
>
> What is the best, cheapest hardware that is compatible with the conserver?

Well, how about a partial answer? :-)

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...)

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

Of course, you can also use on-board multi-port cards as
well with Conserver, but I haven't done extensive testing
with those. Perhaps others on the list can offer their own
experiences with various vendors and models. :-)

-Z- http://www.conserver.com/consoles/

On Tue, 22 Jan 2002, David Harris wrote:

> On Tue, Jan 22, 2002 at 03:03:20PM -0600, Kailash Kayastha wrote:
> > Hello:
> >
> > What is the best, cheapest hardware that is compatible with the conserver?
>
> Well, how about a partial answer? :-)
>
> 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...)
>
> 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
>
> Of course, you can also use on-board multi-port cards as
> well with Conserver, but I haven't done extensive testing
> with those. Perhaps others on the list can offer their own
> experiences with various vendors and models. :-)
>

I have heard anecdotal evidence that the GNP cards 'do the right thing'.
I can say that the Aurora sbus cards do send a break to 'most' attached
hosts 'most' of the time when the box experiences a power incident.

(Generally, I use 4 strand phone cable for console runs as it saves
a lot of space, running through the racks, is easier to trim to
custom lengths, and for some reason, the capacitance in the parallel
strands seems to be just enough to inhibit 'bad breaks' in some cases.
It seems the longer the run the better, ironically. ;)

Doug

David Harris wrote:

> On Tue, Jan 22, 2002 at 03:03:20PM -0600, Kailash Kayastha wrote:
>
>>Hello:
>>
>>What is the best, cheapest hardware that is compatible with the conserver?
>>
>
> Well, how about a partial answer? :-)
>
> 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...)
>
> 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
>
> Of course, you can also use on-board multi-port cards as
> well with Conserver, but I haven't done extensive testing
> with those. Perhaps others on the list can offer their own
> experiences with various vendors and models. :-)


We've used cyclades cards (Y series) for coming up on a year now without
any problems. The SUN break stuff is a pain but we've been using the
alternate break setting and not had any problems with that so far (touch
wood).

[. 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>

On Tue, 22 Jan 2002, Greg A. Woods wrote:

>
> 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).
>
... <electrical specifications elided>
>
>
> 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. :-)
>

I would swap these around. I would start with a good terminal server
that doesn't send false breaks when power cycled. The cisco 36XX series
is one such. You can power cycle the box all you want and it will not
send a break during such an event. There are others popping up
Perle -
http://www.perle.com/products/prod_family/console_server/cs9000.html
Digi, Lantronix, Xyplex
(see evals: http://www.datacomideas.com/SunSafe.html)

If I was going to buy one today (and my company wasn't strongly
wedded to Cisco already), I'd get one of these:
http://www.lantronix.com/products/cs/scs1600_3200/index.html.
They have an optional module that is controlled by a cable from
the console server that allows you to power cycle the host as well.

Also see NuData's product, which you can plug into the serial port
of a Sun to prevent erroneous breaks:
http://www.nudata.com/pdf/CUS4324_Sellsheet.pdf


I realise the point that Greg is trying to make, but, IMHO, one should
try any/all of the above solutions long before taking the possibility
warranty voiding and manual act of soldering components onto your
serial port hardware. These vendor solutions have been evaluated by
third parties and determined to work.


PS - not since sparc1 days have I had any trouble disconnecting the
serial cable from the Sun side of serial connection. No breaks.

Doug