Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!sdcsvax!ncr-sd!greg
From: greg@ncr-sd.UUCP (Greg Noel)
Newsgroups: net.unix-wizards,net.unix
Subject: Re: Arcane modem configuration (was Re: Modems on Ultrix)
Message-ID: <1149@ncr-sd.UUCP>
Date: Sat, 23-Aug-86 05:44:31 EDT
Article-I.D.: ncr-sd.1149
Posted: Sat Aug 23 05:44:31 1986
Date-Received: Sat, 23-Aug-86 20:08:36 EDT
References: <282@cirl.UUCP> <3030@umcp-cs.UUCP>
Reply-To: greg@ncr-sd.UUCP (Greg Noel)
Distribution: net
Organization: NCR Corporation, San Diego
Lines: 95
Xref: mnetor net.unix-wizards:7665 net.unix:5269

In article <121@grebyn.UUCP> karl@grebyn.UUCP writes:
>	[ discussing modem control on lines] ....  The standard configuration
>	is for hardwired terminals, not modems.  Another way (kludge) is to
>	wire your modems up so that DTR is always present.

A nit, but that should be DCD (Data Carrier Detect) instead of DTR (Data
Terminal Ready).  The modem looks at DTR to see if the computer is active,
while the computer looks at DCD to see if the modem has a data connection.
The computer will provide DTR to the modem even if it is ignoring DCD.  (The
modem also provides DSR (Data Set Ready) to say that it is powered on and
ready; this could be used for controlling access to an auto-dialer, but it
usually isn't.)

>	This is a REALLY BAD THING to do, but doesn't require you to
>	reconfigure your system ......

I agree strongly.  See below.

In article <282@cirl.UUCP> das@cirl.UUCP (Dave Steffens) says the same
thing, in a slighly different context:

[ talking about how to assign the per-device modem control bits ]
>NOTE: you cannot just set the all the bits to zero because once
>a line is configured to use modem signals it will not be usable
>with a directly-connected terminal!

In article <3030@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) replies:
>This is my real point of contention.  This is not in fact the case!
>We run most of our terminal lines wired as follows:
			(I have annotated this below)
>	1-----1		(Shield Ground)
>	2-----3		(i.e., cross Transmit Data (TD) with 
>	3-----2			Receive Data (RD))
>
>	4-+ +-4		(Jumper Request To Send (RTS) into Clear
>	5-+ +-5			To Send (CTS))
>
>	6-+--20		(Convert Data Terminal Ready (DSR) into Data Set
>	8-+			Ready (DSR) and Data Carrier Detect (DCD))
>
>	7-----7		(Signal Ground)
>
>	20--+-6		(DTR becomes DSR and DCD again)
>	    +-8
>
>.......  The above constitutes a `null modem' cable,
>crossing various signals around such that, while the terminal is
>on, the host sees a modem `carrier detect' signal.

Chris then points out that this permits \all/ lines to be treated as
modem lines and some rationale as to why this is a good idea.  In this
he is absolutely correct, and I would have quoted it as well except
that I'm already quoting too much.  I will only add that treating all
lines as modem lines is a big plus to system security.

I wish that this diagram would be taken down and added to every SAs
little bag of Elvish tricks -- it's amazing how often this is done
wrong.  The fundamentals of this are simple: TD at one end becomes
RD at the other, and DTR at one end becomes DSR and DCD at the other.
A lot of people seem to think that because most DTEs always provide
RTS at the same time as DTR that these signals are equivalent.  This
is just flat wrong, and will someday lead you into trouble.

(Er, oops, DTE is Data Terminal Equipment, something that "looks like"
a terminal or a computer port.  The other partner is a DCE for Data
\Communications/ Equipment, something that "looks like" a modem.  The
theory is that a DTE can be connected to a DCE by a straight cable.)

About the only thing I do differently is to cross RTS and CTS instead
of jumpering them.  This is useful on those terminals that will do
hardware flow control (I'm not a fan of terminals that sent ^S and ^Q
for flow control) and usually harmless otherwise.

Other notes: Depending upon circumstances, you can frequently get by
without connecting pin #1, or by jumpering it to pin #7 -- computer
boards often connect them internally.  And often in a direct computer-
to-terminal connection, the terminal doesn't care if DSR/DCD is set,
so you can do without that wire.

Thus is it possible to run a hard-wired terminal cable with only three
wires plus a ground.  In fact, if the computer end is connected to the
same board, the ground can be shared -- I have connected eight terminals
to a DH on a PDP-11 over a standard 25-wire cable.  (I don't recommend
this, and there were unusual circumstances that forced me to do it, but
it does show that it is possible to have a secure terminal connection
with a very modest investment in wires.)

I am considered somewhat of a security fanatic, but the additional security
aspects alone are sufficient reasons for me to recommend that you turn on
modem control on all your ports, and then wire your connections to fit that
paradigm, rather than treating "modem" ports as a special case.  Believe me,
it's worth it.  See Chris's article for human-engineering reasons; if my
recomendation doesn't sway you, then those should.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA