Re: Serial Connection -- shielding
On Wed, 30 Mar 2011 06:30:59 -0400 (EDT), MAROUNI Abbass wrote:
> On Tue, 29 Mar 2011 21:27:39 -0400 (EDT), Stephen Powell wrote:
>> As I've said before, the devil is in the details. You need to find out
>> *exactly* how your cross-over cable or null modem is wired. There may
>> be some asymmetry in the wiring that causes the cable to behave differently
>> in opposite directions. The wiring should be symmetrical, ideally as
>> shown in the following URL:
>> The other possibility is that the serial communications settings
>> are different. For example, minicom (or getty) might not be
>> configured exactly the same on both servers. (Data bits, stop bits,
>> parity, bit rate, type of flow control, etc.)
>> It really is much
>> easier with two serial ports per server and two serial cables.
>> Connect /dev/ttyS0 on server 1 to /dev/ttyS1 on server 2 and
>> connect /dev/ttyS0 on server 2 to /dev/ttyS1 on server 1. Have
>> getty listen on /dev/ttyS0 on both servers. Have minicom open
>> /dev/ttyS1 on both servers. I realize its two cables instead
>> of one, but operationally it's much simpler. You want to do it
>> with one cable? How about TCP/IP over ethernet and ssh sessions?
>> That way, you can connect to any PC in the network with just one
>> cable per server.
> The Two servers are exactly the same. getty and minicom have the same
> exact parameters.
> We need to use the serial connections in case one server is unaccessible
> or haven't come up after a restart, so we can connect to its pair and
> pass through the serial connection to see what's happening. The idea of
> using a single cable is to enconomise. I thought it would be relativley
> simple since it's logically possible. I migth need to check the cables
> but I think it's the standard Null modem.
> I thougth that it had something to do with port0 (ttyS0), but if the OS
> treats all the serial ports the same then it's not a software issue?
As another poster has said, another thing you can try is to physically
reverse the two ends of the serial cable to see if its a wiring
But as to using only a single serial cable, either you haven't thought
things through well enough or I don't understand something. You say
that "We need to use the serial connections in case one server is
unaccesible or haven't come up after a restart, so we can connect to its
pair and pass through the serial connection to see what's happening.
The idea of using a single cable is to enconomise." I understand the
desire to save money. But let's think this through.
Let's say that
things are currently set up for server 1 to login to server 2 via the
serial connection. server 1 is running minicom and server 2 is running
getty. If there is a problem with server 2, you may be able to use
server 1 to diagnose the problem. That is the intention. That's what
you want. But suppose its the other way around. Suppose you have
a problem with server 1 and you want to use server 2 to diagnose it.
The first thing you need to do is to reverse the direction. You
can kill getty on server 2, since you presumably have access to its
console. But how to you kill minicom on server 1 and start getty
on server 1? You don't have access to it, remember? You can't
reverse the direction of communications without physical access to
*both* servers. That is why you need two serial ports on each server
and two properly-wired cross-over cables. If you only care about
one-way control, then why do you even care about being able to
reverse the direction of communications?
.''`. Stephen Powell
: :' :