>I'm having trouble connecting to the modem port with 'cu'.  From the SLIP faq:
>
>        % cu -l /dev/tty00 -s 19200  (assumes your modem is on the modem port)
>
>The above produces an error:
>        /dev/tty00: Permission denied.
>        /dev/tty00: Line in use.
>
>        Disconnected.
>
>I've checked that /etc/ttys has tty00 set to "unknown off secure", and ps
>-ax doesn't show any getty's for tty00.

One quick (probably obvious) question: do you have access permission
to /dev/tty00?  As I recall the installer "Create Devices" command
creates /dev/tty00 with either root or uucp ownership, and a 600
access mode.

If that's not it, and there is a modem connected to this port, you've
probably run into the same problem I did last weekend in setting up
uucp.  Try (as root) "echo foobar > /dev/tty00 &" with the modem
connected and disconnected.  If it hangs (hence the background job)
with the modem connected, you've run into the same problem I did.

If DCD is being driven inactive, you can't open the port.  Which puts
you in a Catch-22, since you can't open the port with DCD off, but you
can't turn on DCD (ie, connect to a remote modem), until you open the
port (and send a dial command).  If you are only using the port as a
dial out port, then you can solve the problem by simply configuring
the modem to always assert DCD, regardless of connection status (I had
the same problem on a Sun-3 years ago and did this).  Just be sure
getty isn't running on the port, or bad things happen: getty sees DCD
active, and assumes a remote modem connected.  It puts up a login
prompt, which the modem echos back.  Getty thinks someone is logging
in, and prompts for a password.  The modem echoes back "password:",
and so on.  This continues forever, until getty dies, or sucks down
large chunks of CPU time playing ping-pong with the modem.

Ideally, you don't want to use DCD for flow control, but I didn't seem
to have any luck playing with the flags in /etc/ttys.

The problem is the 8530 SCC's brain-dead "auto-enables" mode.
Auto-enable which lets you enable hardware flow control without any
software intervention.  On the transmit side, the transmitter is
automatically disabled if CTS goes inactive (so far, so good).
Unfortunately, on the receive side, things fall apart.  If DCD goes
inactive, the receiver is disabled, which, when dealing with a modem,
is definately not what you want (in fact, you really don't want to
disable the receiver at all, at least not under normal circumstances -
if you want to disable the receiver at all, you should use DSR).

This isn't that hard to fix, it just requires a little processing
on every external/status interrupt.  I was going to take some time
and look at it at some point (I want to enable dial-in access).

Greg