I'm trying to set up a system for both dialin and dialout on the same serial
port and modem, without success.  The system is a pentium (asus p55tp4xe)
running stock netbsd 1.1.  All added cards (NCR SCSI, display, and ethernet)
are PCI.  The serial port in question is on the motherboard.

  I've looked over the relevant discussions that took place on one or more of
these lists last spring or summer.  Much of that material centered on whether
it was better to do this by having getty block waiting for carrier and having
dialout programs do non-blocking opens and set CLOCAL to do initial
communication with the modem, or to use two different minor device numbers to
refer to blocking and non-blocking devices associated with the same port.
The bottom line is that the current system uses the former approach.  However,
as was pointed out by a couple of people during that discussion, unless getty
observes the port-locking protocols used by the comm programs (kermit, uucp,
tip), when one attempts to dial out using one of these, which must set CLOCAL
to talk to the modem initially, getty will detect carrier and try to do its
thing on the port.  After a quick perusal of the getty code, I have the
impression that it does not check for port lock files.  Indeed, its behavior
supports that conclusion, for if I connect to the port with kermit and set up
the modem to provide echoing and response codes, getty and the modem enter an
infinite dialog and no further progress can be made.  Even if I leave the
modem set to not provide echoes and responses, getty gets into the act once
a connection is made and real carrier is present, again preventing further
progress.

  uucico behaves somewhat differently: it sends the modem setup string and
waits for the "OK" response, which it never receives if getty is running.
The modem's "read data" light flashes, indicating that it did send the response,
but uucico never sees it.  There is no further evidence of traffic on the
modem lights, indicating that the infinite dialog problem that occurs with
kermit does not occur with uucico.  When uucico times out after waiting for
"OK", it drops DTR and exits.  At that time getty dies, so DTR stays low
forever after.

  So:

(1) Is it indeed impossible to do both dialin and dialout on one port
    with 1.1, or is there some trick that I've missed?  I'm just turning
    the port "on" in /etc/ttys, using one of the "std" gettytab entries.

(2) Has anyone already worked out a fix to get around this problem in 1.1?
    (I've seen some patches for 1.0 that take the two-device approach, but
    that seems philosophically incompatible with the approach taken in the
    existing system, which ought to be made to work if it doesn't already.)

  Thanks.

--Jim Bernard
  jbernard@iola.mines.edu