[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Serial Connection -- shielding

Le 31/03/11 13:30, Stephen Powell a écrit :
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
symmetry issue.

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?

In a production environment, this what will happen :

Two servers connected with a single serial cable ( Which I need to figure out how?! :) ), ttyS0 on server1 to ttyS0 on server2. getty is always listening to the ttyS0 port on both servers (assured by inittab respawn).

Server1 is inaccessible. login to server2 launch a script that will kill getty and comment its entry from inittab then launch minicom toward ttyS0 on server1 login to server1 and find what happened. Finally on server2 quit minicom launch another small script that would put getty on ttyS0 and uncomment its entry from inittab. This way if something wrong happens to server2 I am sure that I have a getty on its ttyS0 and all I need to do is to go to server1 follow the same procedure.
Reverse communication assured :)

Logical isn't? :)

I am still not convinced that the serial cable might have different ends if it's a standard null modem cable, so I don't think that reversing the ends between the two servers might help.


Internet Memory Foundation

Reply to: