*BSD News Article 18628


Return to BSD News archive

Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Problems with patchkit 0.2.4
Message-ID: <1993Jul20.012738.2952@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University, Ogden, UT
References: <1993Jul15.070541.27917@cnplss5.cnps.philips.nl> <224in8$fl0@acsc.com> <CAAEBo.LFF@cyb.cojones.com>
Date: Tue, 20 Jul 93 01:27:38 GMT
Lines: 79

In article <CAAEBo.LFF@cyb.cojones.com> loodvrij%cyb@fredbox.cts.com writes:
[ ... nullmodem cables ... ]
>Huh?  Unless you have very wierd ports or modems, the cable should be straight
>through!  You only need a null-modem if you're connecting 2 computers, usually.

Actually, the only time you can safely use CTS/RTS is with either weird
ports or weird modems or both.  The way CTS/RTS is handled under UNIX has
been traditionally bizzarre, starting with the Bell 103 DataSet (modem),
and the expectations of the drivers has never been corrected away from this.

In General, assert/deassert of RTS by the computer can be used, but most
modems won't assert without DCD present (unlike the 103 DS which asserts
when powered on and attached to a line).  The use of CTS/RTS as modem
controls predates by decades their use as out-of-band flow control for
computer systems... after all, buffering data in modems is the relatively
new result of modems that lie about the number of characters they can send
per second by using a baud rate higher than their communication baud rate
to the line to communicate with the host computer.

Valid uses include system-to-system with bizarre drivers and system to
terminal with null-modem cables... this assumes that everything involved is
DTE, not DCE.

Refer to Appendix A of "Technical Aspects of Data Communications", McNeeley
(sp?), Digital Press.


The problem is the deassert of CTS by the modem when DCD is not present
but DTR is asserted.  Consider the scenario where the user hangs up rather
than logging out and CTS is deasserted by the modem before DCD is deasserted.

The connection is hung until the next caller, since on-to-off DCD is not seen,
since the device is flow-controlled (this is especially true if there is
a single input/output queue, such as in VMS or the Altos "multidrop" board
device drivers, and there is pending output that must be flushed for modem
signal status changes to be recognized).  The next caller in, however,
causes the modem to assert DCD prior to CTS, so the connection is never
dropped (security problem).

A subsequent problem is caused by the baud-rate recognition mechanism in
getty: namely, the break key.

If the previous caller was at another baud rate, there is never an on-to-off
transition of DCD to reset to a reall getty to do baud rate recognition.
Similarly, stupid modems (like Avatek 2400's) won't answer at a different
speed until an on-to-off transition of DTR has caused the modem to reset
as if powered off then back on (communication problem).

>The wiring I use for null modems (I'm using one with NetBSD right now) is
>cross RX/TX, RTS/CTS, and DTR/DCD and wire signal ground straight through.
>Some books also tell you to connect DTR and DSR at each end (ie not through
>the cable, but just within the connector), but I've left DSR unconnected
>and it seems to work fine.

The cable you recommend is the one from page 132 (or so) in McNeeley.  It is
correct only for devices with the same idea of the meaning of CTS/RTS.  It's
wrong here.

Practical experience (since the legal lengths for RS-232C devices are at 50
feet with special cabling) also states that pin 7 should go straight through
but pin 1 (and all other unused wires in the cable) be connected on the end
with the bes ground.  This avoids 0 voltage bias reference based ground
loops (ie: an induced current because of a voltage difference between pin
1 and 7 on either end) and allows the other wires to act as a Farraday cage
for the signal carrying wires.


My advice is to avoid cts/rts wherever possible and to tie it in the cable
hood without a connection between the two machines.  If you *must* have
it because you are using equipment which lies to you in their "rated speeds"
column, then be sure your driver expects the default behaviour and not the
documented behaviour of these lines.


					Terry Lambert
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.