NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/sun/admin/9804

Internet Message Format | 1992-12-30 | 5.5 KB

Path: sparky!uunet!meaddata!dem
From: [e-mail] (David Myers)
Newsgroups: comp.sys.sun.admin
Subject: An FAQ: Using Dial-in and Dial-out on the Same Serial Port
Date: 30 Dec 1992 05:57:11 GMT
Organization: Mead Data Central, Dayton OH
Lines: 116
Message-ID: <[e-mail]>
NNTP-Posting-Host: lake.meaddata.com

   This subject comes up quite frequently on the Net, and the current
FAQ just says RTFM, so I thought I'd write up an actual answer so that
I have something to mail people when I see this question asked over
and over.  And maybe this will find its way into the FAQ.  Please mail
me any corrections.

   *** How to use both dial-in and dial-out on the same serial port on
a Sun running SunOS 4.1.X. ***

   SunOS supports using serial ports bidirectionally, and you don't
need any extra programs like uugetty to do it.  The support is
provided by the standard serial port driver for the zs ports, and many
add-on serial ports (like ALM-2 and CoALM) come with drivers that
provide identical support.  The trick here is to create a second
special device file under /dev that will be used by programs which
dial out, while the original device file is used by getty(1) to handle
programs which dial in.

   To get this to work, you must ensure that the carrier detect signal
(DCD) is being handled normally.  By default, SunOS ships with
so-called "software carrier detection" turned on.  This means that DCD
is held high in software for the benefit of stupid devices that might
be connected to the serial ports.  For modems, this won't do.  You
turn off "software carrier detection" by altering the keyword "local"
in the entry in /etc/ttytab for the port in question.  Then, either
reboot, or use the ttysoftcar(8) command to alter the DCD handling on
the fly.  See the man page for ttysoftcar.

   Once DCD handling is correct, then the getty process you run on the
device (by changing the keyword "off" to "on" in /etc/ttytab) will
block trying to open() the it until DCD goes high, which will be the
case when someone connects to your modem (check your modem settings --
you might need to set AT&C1&W for DCD to be handled correctly).  The
new special device you're about to create, however, will be able to
open() the port with DCD down (as is the case when UUCP wishes to
establish a connection) *unless* the port is already open()ed in the
incoming direction.  Correspondingly, getty won't be able to open()
the port if it's already in use by an outgoing process.

   It's traditional to rename ttya and ttyb to ttyd0 and ttyd1 when using
them for incoming connections.  For one thing, it makes it somewhat
more obvious that someone's dialed in from outside when you see
they're on a ttyd? port.  For another thing, you can have the login(1)
program send immediate notification of someone logging in to a ttyd?
port to (for example) your console by adding a line like the following
to /etc/syslog.conf (and sending a SIGHUP to syslogd):

auth.notice                                  /dev/console

   See the manual page syslog.conf(5) for more information.  The point
is that login knows that a ttyd? port is special, so it's often useful
to do the renaming.

   For the new, outgoing devices, it's traditional to call them cua0
and cua1 (which would correspond to ttyd0 and ttyd1, respectively).  I
don't think there's anything special about these names.

   You create the new devices in /dev so as to have the same major
device numbers as the already existing devices, but with a minor
device number 128 greater.  Proceed as follows:

# cd /dev
# ls -l tty[ab]
crw-rw-rw-  1 root      12,   0 Dec 11  1990 ttya
crw-rw-rw-  1 root      12,   1 Dec 11  1990 ttyb
# mv ttya ttyd0
# mv ttyb ttyd1
# ls -l ttyd?
crw-rw-rw-  1 root      12,   0 Dec 11  1990 ttyd0
crw-rw-rw-  1 root      12,   1 Dec 11  1990 ttyd1
# mknod cua0 c 12 128
# mknod cua1 c 12 129
# ls -l cua?
crw-r--r--  1 root      12, 128 Dec 30 00:13 cua0
crw-r--r--  1 root      12, 129 Dec 30 00:13 cua1
# chown uucp cua?


   Remember to edit /etc/ttytab and rename ttya and ttyb to ttyd0 and
ttyd1 there, too.

   Finally, make sure programs which initiate outgoing connections use
the cua? devices.  You would change this in /etc/remote for tip(1), and
/etc/uucp/Devices for UUCP.

   As long as you're setting up your serial ports, it's a good idea to
make sure that both your SunOS programs and your modem are using
hardware flow control (also called RTS/CTS flow control).  Some form
of flow control is usually necessary, but using software flow control
(also called XON/XOFF flow control) in your modem will mess up UUCP.

   First, turn on hardware flow control in your modem.  Consult the
manual that came with your modem on how to do this.  For a recent
Telebit modem (QBlazer, T2500, T3000, or WorldBlazer), you'd connect
to the modem and send it the string ATS58=2&W.

   Next, make sure the software using the port knows to use hardware
flow control.  For UUCP, add the following pseudo send string to the
end of the entry or entries you're using in /etc/uucp/Dialers:

    STTY=crtscts

   For getty, add the following capability to the entry or entries
you're using in /etc/gettytab:

    :ms=crtscts:

   Note to ALM-2 users:  Due to severe brain damage, you can only use
hardware flow control on the first four serial ports of the ALM-2.
Yes, you wasted your money.

--
David Myers                                             [phone]
Mead Data Central           No news is             Fabrication Systems
P.O. Box 933                 bad news.                [e-mail]
Dayton, Ohio  45401                             ...!uunet!meaddata!dem