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!math.ohio-state.edu!cs.utexas.edu!utah-morgan!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: <1993Jul21.195633.16780@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <CAAEBo.LFF@cyb.cojones.com> <1993Jul20.012738.2952@fcom.cc.utah.edu> <CAHvz0.38s@cyb.cojones.com> Date: Wed, 21 Jul 93 19:56:33 GMT Lines: 97 In article <CAHvz0.38s@cyb.cojones.com> loodvrij%cyb@fredbox.cts.com writes: >In article <1993Jul20.012738.2952@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > >>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. Only if the drivers on both ends implement it the same way. From a PC to a PC, you are going DTE to DTE (with a nullmodem) so this should be safe. >>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? Nope. Almost all PC serial ports are DTE (Data Terminal Equipment) and almost all modems are DCE (Data Communications Equipment). You don't need a nullmodem going DCE-DTE or DTE-DCE, but *do* if going DCE-DCE or DTE-DTE (think of it like magnets). >>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? Nope. It applies to any implementation of hardware flow control or even in-band flow control, where flow control is managed at or below the layer managing the connection state. This is a bug in most driver (in SVR3, it lived in the sys2.c code with the paritial open hack). [ ... ] >>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? Actually, no; but then flow control is required, so you just exacerbate the CTS/RTS problems. >> [ nullmodem including CTS/RTS is generally wrong ] >It is? Even when connecting one PC to another? Yes, unless the drivers take signal precedence over flow control. Not all hardware signals are equal. For instance, take the case of the terminal or PC hooked to the PC serial port being shut off (basically, DTR [DCD] is dropped at the same time CTS[RTS] is dropped using the nullmodem cable). >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! Yep. >>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? The Telebit can handle CTS/RTS correctly (settings on S registers 21, 23, 81, I think -- it's been a while); the onus is on the serial driver to give priority to the DCD/DSR state and on you to set the modem up correctly. I would *not* lock the baud rate between the modem and the 386BSD box. The current serial driver still has deficiencies in this area, and I would not trust it to handle the wire signals correctly until it has been fixed. This will be a problem for you, since the multicarrier modulation and the LZW compression in the modem will only give you a bursty 14.4, and if you set the port at 19.2, you will eventually overflow the UNIX buffer or get the port hung waiting for CTS and the mode hung waiting for the port to drop DTR for a few ms before it reasserts CTS. Terry Lambert terry_lambert@novell.com --- Any opinions in this posting are my own and not those of my present or previous employers.