Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!news.sol.net!news.sol.net!not-for-mail From: jgreco@solaria.sol.net (Joe Greco) Newsgroups: comp.os.386bsd.bugs Subject: Re: PROBLEMS WITH FreeBSD Date: 31 Dec 1993 18:07:10 -0600 Organization: Solaria Public Access UNIX - Milwaukee, WI Lines: 49 Message-ID: <2g2ere$esn@solaria.mil.wi.us> References: <CIq8w7.7rM@csi.compuserve.com> <2g0kdl$2d9@cleese.apana.org.au> NNTP-Posting-Host: solaria.mil.wi.us In comp.os.386bsd.bugs article <2g0kdl$2d9@cleese.apana.org.au>, newton@cleese.apana.org.au (Mark Newton) wrote: :If you did, and you still couldn't login, then the most likely reason is :that you have dumb 3-wire serial cable. The sio drivers behave like :"real" UNIX tty drivers -- they don't complete their open() until DCD is :asserted unless you disable that feature with ioctl() or tcsetaddr() :(or, from the shell, use "stty clocal"). : :The sio drivers also know about flow control, so if you have 3-wire :null modems which don't have a clue about flow control, you'll have to :use stty -crtscts too. Note that getty will try to turn crtscts back :on (so disabling flow control then starting up getty is a pointless :exercise). : :... : :The solution? Re-config your kernel to use sio, and make yourself some :*REAL* terminal cables. For modems, you just need a straight-through :25pin cable (or, at least, a cable which has TD, RD, CTS, RTS, DCD and :DTR connected). For terminals, you should tie DTR at the terminal's :end to DCD at the computer's end, and perhaps bridge CTS and RTS at :the computer's end (assuming that your terminal is fast enough to not need :any hardware flow control when it's displaying data. You'll need to wire :the flow-control properly if that isn't the case. Most modern terminals :can cope happily with 9600bps with no flow control, though). Now wait a minute. I thought the SIO drivers were supposed to provide bidirectional capability. How is this supposed to work? I've been looking for documentation for about a week, and have yet to find anything. Under SunOS, which IMHO has a "reasonable" bidirectional mechanism, open() will block on the opening of a terminal device unless there is carrier AND the port is not already open in the other direction (cua0 or whatever). cua0 can be opened regardless of the state of carrier, unless the port is already open in the other direction (tty00 or whatever). This allows getty to hang on tty00, and uucp/kermit/tip/cu to call out on cua0, transparently. Ideally, I'd _love_ to see this done with SIO, and I was actually under the impression that SIO had a direct analogy of some sort. Setting clocal or locking DCD in some manner could make all of this rather difficult, if it works at all like any other implementation I've seen. So what's the deal? Does SIO provide bidirectional capabilities? And if so, what is the technique used to implement (and/or use) it? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847