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.