Serial BREAK on console servers

  Actually two very important points have been made here;

  1) Lots of things can cause BREAK, even when there is nothing
     plugged into the console port! (And you may be able to
     build some protecting into the device itself by performing
     some electrical surgery on your devices serial port.)

  2) In most cases (where Conserver is concerned) folks will
     have something plugged into the serial console all the
     time, so it would be better to use a device that doesn't
     send BREAK when the power to the device is removed,
     or even when the port is reset. (This reduces the chance
     thatyou will induce a BREAK when changing cables, etc.)

  I also appreciate that both writers took time to provide 
additional pointers, and to provide some explanations to
help fill out their premises. :-)

  While I appreciate the input, I wanted to explain a couple of 
things that have driven my web pages;

  a) I've been hacking serial for a long while, and I've found
     a lot of trouble sources while working in all aspects of
     communications hardware design, repair, and support. While
     you *could* try to document it all, the audience of folks
     interested in reading it all would be pretty small. (The
     reason why you can't find many good, *complete* books on 
     the topic is because the book publishers don't see a market.)

  b) Most folks searching the web for serial stuff are looking
     for specific, concise information. I've tried to make my
     pages fit that criteria. (And the feedback from readers
     has generally been positive. ;-)

  c) The vendors of console gear really haven't *used it* in
     the reverse-TCP mode...tested, yes, but they haven't
     really deployed it in their own shops, and used it for
     remotely accessing machines...as a result, they haven't
     seen some of the problems. With that said, most of the
     vendors *are* interested in feedback, and improving
     their products. (Note that I said *"most"*...)

  d) In most cases, fixing the BREAK-on-power-cycle problem
     *did* require a hardware redesign...but many vendors
     have made those changes, because they are hearing back
     from customers that "there is a problem", but many of
     those same customers couldn't explain *why* things
     were bad. (Hardware redesign takes time, and costs money.
     If the vendor is selling a product to a large market,
     it will benefit them to make a better product. If a
     vendor only serves a small market, or they have a lot
     of the 'bad' product in their inventory, it is harder
     to convince them to make the investment.)

  e) The BREAK problem really only affects older SUN boxes, and
     some SGI models...while it's a big market, it's only a
     *part* of the total market for this type of device.
     (If you only have one or two SUN boxes, it may be cheaper
     to use the NuData adapters (at $100 per port...), but
     if you have two dozen sun boxes to protect, it's going
     to be cheaper to get a console server that doen't send
     BREAK until you want it to. And this can be a dynamic
     equation, if you are small now, but considering growing
     in the next year or two. :-)

  I'm really glad for Celeste Stokley's pages. There is lot's
of good information there, including the older, legacy stuff.
For those searching for as much knowledge on a topic as they
can find, knowing the legacy stuff is also important. (and
I'm thrilled that she thinks my pages are useful enough to
list there. :-)

  I don't mean to stifle a detailed discussion of RS-232 and
EIA-232 standards and specifics (and normal deviations and etc.),
but I don't know how many folks would want to read about it.
(And I'm wondering if many others might consider it all just
extra noise on the list.) I'm happy to continue the thread in
the topic is because the book publishers don't see a market.
email if folks want. Of course, post to the list whatever you
feel is relavant for the list. :-)

    Regards,

       -Z-