FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 03-28-2011, 08:30 AM
"Russell L. Harris"
 
Default Serial Connection -- shielding

to:
CC:
* Stan Hoeppner <stan@hardwarefreak.com> [110328 06:24]:
> Moczik Gabor put forth on 3/28/2011 12:01 AM:
> > Stan Hoeppner wrote:
> >> We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise
> >> rejection is many times that of CAT3, allowing greater distances across
> >> sprawling warehouses.
> >
> > RS-232 uses single-ended signaling and requires shielded cable, twisted
> > pair doesn't help either.

Shielding provides immunity (not always perfect) against
radio-frequency interference. But shielding (aside from an enclosure
or conduit of iron or steel) provides no immunity against magnetic
fields.

If an RS-232 cable does not run near electric motors or switchgear, or
make a long run parallel to power cables, and if radio-frequency
interference is not a problem, then CAT5, CAT3, or even multiple
strands of lamp cord may be satisfactory, without a shield. In fact,
lamp cord -- typically 18 AWG stranded copper -- should allow longer
runs, because of its much lower resistance (and thus, lower signal
attenuation). And, at some point, capacitance of the circuit can
become a problem, because it limits the usable data rate.

RLH

--

Who is this that darkeneth counsel by words without knowledge? - Job 38:2


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110328083033.GB3041@cromwell.tmiaf">http://lists.debian.org/20110328083033.GB3041@cromwell.tmiaf
 
Old 03-29-2011, 02:18 PM
MAROUNI Abbass
 
Default Serial Connection -- shielding

Le 28/03/11 10:30, Russell L. Harris a écrit :

to:
CC:
* Stan Hoeppner<stan@hardwarefreak.com> [110328 06:24]:

Moczik Gabor put forth on 3/28/2011 12:01 AM:

Stan Hoeppner wrote:

We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise
rejection is many times that of CAT3, allowing greater distances across
sprawling warehouses.

RS-232 uses single-ended signaling and requires shielded cable, twisted
pair doesn't help either.

Shielding provides immunity (not always perfect) against
radio-frequency interference. But shielding (aside from an enclosure
or conduit of iron or steel) provides no immunity against magnetic
fields.

If an RS-232 cable does not run near electric motors or switchgear, or
make a long run parallel to power cables, and if radio-frequency
interference is not a problem, then CAT5, CAT3, or even multiple
strands of lamp cord may be satisfactory, without a shield. In fact,
lamp cord -- typically 18 AWG stranded copper -- should allow longer
runs, because of its much lower resistance (and thus, lower signal
attenuation). And, at some point, capacitance of the circuit can
become a problem, because it limits the usable data rate.

RLH


I think that the discussion diverted somehow from my original question.

My problem was the following :
Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0
connected to ttyS1 on Z1.

on ttyS0 on Z0 I have a getty listening for incoming connections.
on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally.

Now When I try to do the inverse :
Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to
listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1.


I can't login all I see is garbage. All the serial parameters are the
same on both sides.
I thought that logically this setup have to work since I am using the
same setup just changing which port on which server.


I am trying to do this for a Datacenter with hundreds of servers. This
way I can connect two servers together with just one serial cable.


Does it have something to do with the ttyS0 port? is it a software problem?

Do you have any ideas ? (Apart from theoretical discussions about all
the standards)


--
Abbass MAROUNI
Internet Memory Foundation
internetmemory.org



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D91EA4A.8080804@internetmemory.org">http://lists.debian.org/4D91EA4A.8080804@internetmemory.org
 
Old 03-30-2011, 01:27 AM
Stephen Powell
 
Default Serial Connection -- shielding

On Tue, 29 Mar 2011 10:18:50 -0400 (EDT), MAROUNI Abbass wrote:
>
> I think that the discussion diverted somehow from my original question.
>
> My problem was the following :
> Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0
> connected to ttyS1 on Z1.
> on ttyS0 on Z0 I have a getty listening for incoming connections.
> on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally.
>
> Now When I try to do the inverse :
> Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to
> listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1.
>
> I can't login all I see is garbage. All the serial parameters are the
> same on both sides.
> I thought that logically this setup have to work since I am using the
> same setup just changing which port on which server.
>
> I am trying to do this for a Datacenter with hundreds of servers. This
> way I can connect two servers together with just one serial cable.
>
> Does it have something to do with the ttyS0 port? is it a software problem?
>
> Do you have any ideas ? (Apart from theoretical discussions about all
> the standards)

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:

http://en.wikipedia.org/wiki/File9_Null_Modem_Wiring.png

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.

--
.'`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1491094980.1812990.1301448459743.JavaMail.root@md0 1.wow.synacor.com">http://lists.debian.org/1491094980.1812990.1301448459743.JavaMail.root@md0 1.wow.synacor.com
 
Old 03-30-2011, 07:38 AM
Scott Ferguson
 
Default Serial Connection -- shielding

On 30/03/11 01:18, MAROUNI Abbass wrote:
> Le 28/03/11 10:30, Russell L. Harris a �crit :
>> to:
>> CC:
>> * Stan Hoeppner<stan@hardwarefreak.com> [110328 06:24]:
>>> Moczik Gabor put forth on 3/28/2011 12:01 AM:
>>>> Stan Hoeppner wrote:

<snipped>

> I think that the discussion diverted somehow from my original question.
>
> My problem was the following :
> Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0
> connected to ttyS1 on Z1.
> on ttyS0 on Z0 I have a getty listening for incoming connections.
> on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally.
>
> Now When I try to do the inverse :
> Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to
> listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1.
>
> I can't login all I see is garbage. All the serial parameters are the
> same on both sides.

Which are?

> I thought that logically this setup have to work since I am using the
> same setup just changing which port on which server.

Logically yes, *if* you covered the other half of the possible
combinations - it is unclear from my interpretation of your post. (I can
only 'assume' you can remove it from inittab)

>
> I am trying to do this for a Datacenter with hundreds of servers. This
> way I can connect two servers together with just one serial cable.
>
> Does it have something to do with the ttyS0 port? is it a software problem?

It could be both - or either, with out knowing the server setup, chipset
details etc and security policies I can only guess.

>
> Do you have any ideas ? (Apart from theoretical discussions about all
> the standards)
>

When I have previously encountered the situation you describe it was on
systems using hardware control, and solved by using software control.
I suggest you make sure you are using software control on *both* ends.

Ensure you are not using -h when setting up the getty session (no
hardware control)
When starting the minicom session are you using software control? Check
the global conf file, somewhere in /etc usually.

Are the chipsets identical on both servers? There are/were some
problematic serial chipsets.
Perhaps if you post the exact commands you are using to start your getty
sessions, your minicom global config, and what commands you are entering
into minicom it might be easier to diagnose.

Output of setserial from both machines might also be instructive.

Cheers

--
Tuttle? His name's Buttle.
There must be some mistake.
Mistake? [Chuckles]
We don't make mistakes.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D92DE0E.9090001@gmail.com">http://lists.debian.org/4D92DE0E.9090001@gmail.com
 
Old 03-30-2011, 10:30 AM
MAROUNI Abbass
 
Default Serial Connection -- shielding

Le 30/03/11 03:27, Stephen Powell a écrit :

On Tue, 29 Mar 2011 10:18:50 -0400 (EDT), MAROUNI Abbass wrote:

I think that the discussion diverted somehow from my original question.

My problem was the following :
Two identical servers Z0& Z1 and a null modem cable. ttyS0 on Z0
connected to ttyS1 on Z1.
on ttyS0 on Z0 I have a getty listening for incoming connections.
on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally.

Now When I try to do the inverse :
Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to
listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1.

I can't login all I see is garbage. All the serial parameters are the
same on both sides.
I thought that logically this setup have to work since I am using the
same setup just changing which port on which server.

I am trying to do this for a Datacenter with hundreds of servers. This
way I can connect two servers together with just one serial cable.

Does it have something to do with the ttyS0 port? is it a software problem?

Do you have any ideas ? (Apart from theoretical discussions about all
the standards)

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:

http://en.wikipedia.org/wiki/File9_Null_Modem_Wiring.png

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?


Merci,

--
Abbass MAROUNI
Internet Memory Foundation
internetmemory.org



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D930663.50807@internetmemory.org">http://lists.debian.org/4D930663.50807@internetmemory.org
 
Old 03-30-2011, 03:32 PM
Moczik Gabor
 
Default Serial Connection -- shielding

MAROUNI Abbass wrote:
The Two servers are exactly the same. getty and minicom have the same
exact parameters.


Which are top secret. :-)


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?


If you reverse the cable, it works?

You can try this tool for hardware-related diagnostics, but it's for
windows. I'm using it for electronic development, if anyone knows an
equivalent for linux, I'm interested too.

https://sites.google.com/site/terminalbpp/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D934CFD.9050206@progzmaster.hu">http://lists.debian.org/4D934CFD.9050206@progzmaster.hu
 
Old 03-31-2011, 11:30 AM
Stephen Powell
 
Default 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:
>>
>> http://en.wikipedia.org/wiki/File9_Null_Modem_Wiring.png
>>
>> 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?

--
.'`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 790100680.1843209.1301571043112.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/790100680.1843209.1301571043112.JavaMail.root@md01 .wow.synacor.com
 
Old 03-31-2011, 01:14 PM
MAROUNI Abbass
 
Default 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:

http://en.wikipedia.org/wiki/File9_Null_Modem_Wiring.png

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.



Thanks.

--
Abbass MAROUNI
Internet Memory Foundation
internetmemory.org



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D947E1F.2020109@internetmemory.org">http://lists.debian.org/4D947E1F.2020109@internetmemory.org
 
Old 03-31-2011, 02:29 PM
Moczik Gabor
 
Default Serial Connection -- shielding

MAROUNI Abbass wrote:

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


This may not work as expected.
I think you intend to enable kernel and grub serial console too (good
idea for remote diagnostics). This way, if you start both servers, one
of them starts getty earlier (asking for login/password), while the
other still sending its console messages, login prompt, etc., straight
into the getty's stdin on the first server.


I am still not convinced that the serial cable might have different ends


normally... but might be defective...


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4D948FB3.4080208@progzmaster.hu">http://lists.debian.org/4D948FB3.4080208@progzmaster.hu
 
Old 03-31-2011, 04:13 PM
Stan Hoeppner
 
Default Serial Connection -- shielding

Stephen Powell put forth on 3/31/2011 6:30 AM:

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

This is exactly why all tier one, and some tier 2, vendors ship servers
with lights out management boards pre-installed. This is also exactly
why their predecessor, rack mount KVM over IP devices, were invented, oh
so long ago.

I dare say that if you're too cheap to use one of these proven solutions
then you have no business running a server that needs uptime and quick
diagnosis upon failure.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D94A814.1030503@hardwarefreak.com">http://lists.debian.org/4D94A814.1030503@hardwarefreak.com
 

Thread Tools




All times are GMT. The time now is 06:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org