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