Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!newshub.nosc.mil!crash!fredbox!cyb!terminator!loodvrij From: loodvrij@cyb.cojones.com (Bruce 'Loodvrij' Keeler) Newsgroups: comp.os.386bsd.bugs Subject: Re: Problems with patchkit 0.2.4 Message-ID: <CAHvz0.38s@cyb.cojones.com> Date: Wed, 21 Jul 1993 03:20:45 GMT References: <1993Jul15.070541.27917@cnplss5.cnps.philips.nl> <224in8$fl0@acsc.com> <CAAEBo.LFF@cyb.cojones.com> <1993Jul20.012738.2952@fcom.cc.utah.edu> Reply-To: loodvrij%cyb@fredbox.cts.com Organization: The museum of ancient wombats Lines: 101 In article <1993Jul20.012738.2952@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >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. > Ah... Just when I thought I was getting the hang of it.... >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. Well, currently I have two computers conencted by null modem, so the point about modems being locked at higher rates than they can send is not really relavant. The reason I wired up RTS/CTS in the first place was so I can run slip safely over it - other posts have implied that hardware handshaking is a good idea with slip. >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. I would have thought everything in my system would be DCE, no? >Refer to Appendix A of "Technical Aspects of Data Communications", McNeeley >(sp?), Digital Press. Hmmm. I don't have that book, but I'll look out for it. In fact the only book I had handy was 'Managing UUCP and USENET' from O'Reily, which goes into it briefly. >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. This is wrt wierd old Bell modems, not nice modern compressing ones, right? >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). OK, I see this. >A subsequent problem is caused by the baud-rate recognition mechanism in >getty: namely, the break key. I see this too, though this probably wouldn't be a problem with a modem that locks the connection to the computer at a high baud rate, would it? >> [null modem cable description...] >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. It is? Even when connecting one PC to another? >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. > Hmmmm. Pin 1 is chassis ground or something isn't it? I wired that up to the screen of the cable. The other end was a 9 pin connector which doesn't appear to have an equivalent pin, so I left the screen unconnected. Seems I did more or less the right thing without knowing it! > >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. OK, so I'll kill rts/cts for now, then? But if I get a high speed modem (I'm saving up for a Telebit WorldBlazer right now) I guess I'll have to use it. Does 'making sure the driver expects the default behaviour' mean doing a 'stty crtscts' or whatever? > Terry Lambert > terry@icarus.weber.edu >--- >Any opinions in this posting are my own and not those of my present >or previous employers. Bruce