Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.mail.uucp
Subject: Re: Bidirectional Modem Lines under SunOS 4.0.1
Message-ID: <1395@auspex.auspex.com>
Date: 7 Apr 89 06:17:32 GMT
References: <160@osc.COM> <743@key.COM> <2209@laidbak.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 122

>>Sounds like your setup doesn't properly handle the CD (carrier detect)
>>signal. In the correct setup, getty will hang on the open(2) call for
>>the modem because CD is down (off) until somebody actually dials in and
>>the modem connects and turns CD on. Conversely, the corresponding
>>/dev/cua* device will return open errors while CD is up (because the line
>>is currently used for dial-in).
>
>If you think about it, this won't work.

Yes, but it works nonetheless, which means you have to think a bit
harder.  See below....

>The dial out will cause CD to go high and the getty to complete its
>open.  There has to be additional lock to secure access to the tty.

Nope.  The scheme used in, among other places, SunOS, has *two* device
files that refer to the same serial port.  One is the "dial-in" device,
and has "getty" (or "init", on older systems) running on it waiting for
somebody to dial in.  The other is the "dial-out" device, and is what
UUCP, "tip", "cu", etc., etc. use to dial out on that line.

Opens on the "dial-in" device block until carrier comes up (unless
you've not turned "soft carrier" off - more on this below).  Opens on
the "dial-out" device succeed even if carrier isn't up, so that you can
talk to the modem.  In addition, once the dial-out device is open, any
opens on the dial-in device that are waiting for carrier to come up will
*NOT* complete when carrier comes up!  CD will come up if the dial out
succeeds; however, this will *not* cause the "getty" to complete its
open.  Only when the program dialing out is done with the line, and
closes it, does the line revert to "normal" mode, in which carrier
coming up causes the "open" to complete; if the dial-out device is
opened again, the "getty" will again not complete its "open" if carrier
comes up.

Attempts to open the dial-out device while the dial-in device is open
fail with an error (EBUSY in SunOS 4.0).

In SunOS, the dial-in device is generally named "/dev/ttydN", for some
value of N, and the corresponding dial-out device is generally named
"cuaN" or "cuN" or something such as that (this isn't an absolute
requirement, though, as far as I know).

>In the bidirectional setups I've seen this is done with the LCK..tty
>file.  Getty opens the tty and then *tries* to create the lockfile,
>cu/uucico creates the lockfile and then opens the tty.  There is still
>a little time for a dialin user to get hosed here though.

In the bidirectional setup I've seen, namely the SunOS one, "getty"
knows absolutely nothing about UUCP lock files, which is nice; you don't
have to change "getty" to have it work with this scheme.  I think most,
if not all, of the window in the other scheme is closed with the
two-devices scheme.

>I have no experience with Sun uucp (other than the fact that its HDB).

Either:

	1) you have experience with the SunOS 4.1 UUCP;

	2) your experience with the SunOS UUCP comes from connections
	   with Sun's UUCP machine "sun";

or

	3) you have even less experience with the Sun UUCP than you
	   think;

because, in the current release, it's *not* HDB.  4.1 will have HDB, and
that version of UUCP is what's running on "sun" right now, but systems
in the field don't have it.

>>Next potential gotcha: for similar reasons, the default configuration
>>of the serial drivers pretends that the CD signal is always on, no matter
>>what the hardware says (does that start to sound familiar?!).
>
>The file /usr/include/sys/tty.h on my Sun 3.5 system does not have the
>NOHANG tty mode flag that I've seen in other kernels to prevent the blocking
>on the open system call.

Well:

	1) NOHANG sure doesn't do that under BSD - it only prevents
	   SIGHUP from being delivered when carrier goes down.  The way
	   you prevent the blocking on the open system calls in 4.xBSD,
	   for x >= 2, is to use the O_NDELAY flag on open.

	   The SunOS 3.5 tty driver is mostly based on the 4.3BSD one; I
	   think it has NOHANG.  However, <sys/tty.h> is the wrong place
	   to look; it's in <sys/ioctl.h> in 4.3BSD, and probably in
	   SunOS 3.5 as well.

	2) The default configuration *does*, in fact, pretend that the
	   CD signal is always on, no matter what the hardware says,
	   precisely as the previous poster stated.  This is the "soft
	   carrier" I referred to above.

	   In order to turn "soft carrier" off for a port, you have to
	   reconfigure your kernel - except, I think, on the Sun386i,
	   where there may be:

		1) a flag "local" in "/etc/ttytab" to specify that a
		   line has "soft carrier" enabled;

		2) an "ioctl" TIOCSSOFTCAR that permits you to set or
		   clear the "soft carrier" flag for a tty port, and an
		   "ioctl" TIOCGSOFTCAR that gets the state of the "soft
		   carrier" flag for a port;

		3) a program "ttysoftcar" that can be told to scan
		   "/etc/ttytab" and set soft carrier appropriately and,
		   possibly, to individually set or clear "soft carrier"
		   on a port and print the status of "soft carrier" on
		   that port.

	   If you have a 386i, check whether there's a "local" field on
	   the line in question in "/etc/ttytab"; if so, remove it, and
	   try running "ttysoftcar -a", which I think may be the flag to
	   scan "/etc/ttytab" (I didn't write it, and don't remember the
	   details).  Try "ttysoftcar -!" or something else to provoke
	   it into issuing a usage message; unfortunately, this stuff
	   was, I think, not documented.  It may show up in the non-386i
	   Suns in a future release, hopefully with documentation....