Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!munnari!murtoa.cs.mu.oz.au!bruce!goanna!koel!chudich!rcodi
From: rcodi@chudich.co.rmit.oz (Ian Donaldson)
Newsgroups: comp.mail.uucp
Subject: Re: Bidirectional Modem Lines under SunOS 4.0.1
Message-ID: <455@chudich.co.rmit.oz>
Date: 11 Apr 89 15:39:47 GMT
References: <1395@auspex.auspex.com>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 34

From article <1395@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris):
> Opens on the "dial-in" device block until carrier comes up (unless
> you've not turned "soft carrier" off - more on this below).  

Hmmm.  A technical point on this... measurements I have made on a Sun-3/260
with both mti and zs serial ports is this:

	DCD - when low, prevents the Sun driver from receiving data.  Any
	      data received in this state is ignored.
	      Opening the cua device when DCD is low succeeds but you
	      can't hear anything!
	      ie: tie Sun-DCD to Sun-DTR so that you can always hear things
	      when the device is open (either via cua or tty open).

	DSR - when low, prevents the Sun driver from allowing open's on
	      the device to complete (unless O_NDELAY is specified or
	      the kernel is configured to ignore "carrier" or a cua open is 
	      attempted).
	      ie: tie Sun-DSR to remote-DTR so that the tty open succeeds
	      when a connection to the remote happens.

	CTS - when low, prevents the serial chip from sending data iff:

		- the zs driver has been patched to set the bit in the
		  scc that enables hardware flow control
		  (patch needed at least on SunOS 3.whatever)

		- using the mti driver, in which case hardware flow control
		  is on all the time, regardless of kernel running.

Other manufacturers may adopt different policies WRT DCD and DSR; DSR is
usually ignored and DCD handles both the data reception and open completion.

Ian D