lenny@icus.ICUS.COM (Lenny Tropiano) (09/24/90)
James Warner Adams <adams@ucunix.san.uc.edu> sent this to me, and I
feel that these questions are coming up more and more. Jim did a
very good job of explaining the procedure, and even though he thought
this was too large to post, the nature of this article will solve
many people's problems as well as keeping down future postings. This,
of course, was too large for inclusion in the FAQ posting, which has
been extensively updated. You will see that by the end of the month,
it's now *two* files since it grew so much.
This file will be archived and updated as necessary on the OSU-CIS Archives.
File: HDB_Modem.Z
============================================================================
How to set up your external modems using HDB (hayes in particular). For
information on how to setup Telebit Trailblazer modems you should
refer to the tb-setup.sh.Z scripts on OSU-CIS Archives.
Written by James Warner Adams <adams@ucunix.san.uc.edu>, additional
comments by Lenny Tropiano <lenny@icus.ICUS.COM>
Last updated: Sun Sep 23 17:29:05 EDT 1990
============================================================================
There is a continuing interest in setup for HDB uucp on the UNIX-PC. There
also seems to be much confusion about uucp administration and the uucp
internals. The following is a synopsis of a uucp setup that works
perfectly on 3.51m. To use a Trailblazer, you should read the info
files on osu-cis. You can follow the same uucp setup, but the 'blazer
needs to be set up to react properly in this context.
This setup applies to external modems. The control of the internal
modem is "compiled in" and cannot easily be changed without the source
code for HDB uucp.
The following is a sample setup for a Hayes-compatible modem on the
built-in serial port. The same setup should work for any expansion port
by simply changing the device name to tty001, etc. Be sure, however,
that you have installed the proper driver software (comes with the
expansion board).
One of the major problems with trying to use a single modem for both
incoming and outgoing communications on a UNIX system is that the
operating system was not originally designed to handle this situation.
Serial ports were expected to be either incoming (login) or outgoing.
As a matter of fact, they were really ONLY expected to be incoming, so
even putting a serial printer on a UNIX system requires some witchcraft
in /etc/rc to 'fool' UNIX into thinking that the printer is 'logged on'
during the boot process. Furthermore, the original system assumed that
there was a separate device called an 'ACU' or Automatic Calling Unit
which handled the dialing. Because of this "ancient history," the
workings of uucp are a bit obscure to the average user.
The following files need to be set up for your installation:
/etc/inittab:
uuk:2:respawn:/etc/killgetty
.
.
.
vid:2:respawn:/etc/getty window 9600
.
.
.
000:2:respawn:/usr/lib/uucp/uugetty -h -t 60 tty000 2400M
note that the dots just represent the space taken up by other entries.
Note also that the killgetty entry may not be necessary in your
installation... it is modem-dependent and is discussed below. Note also
the spaces preceeding the getty/uugetty entries. These are REQUIRED for
the user agent and setgetty to operate properly.
/etc/gettydefs:
2400M# B2400 # B2400 HUPCL BRKINT ISTRIP ICRNL OPOST ONLCR CS8 CREAD ISIG ICANON ECHO ECHOE ECHOK NOFLSH TAB3 #\n\nlogin: #2400M
Note that the gettydefs entry is a single long line. It will probably
appear folded on your terminal. Note also that there MUST be a blank
line at the end of gettydefs. You can check your gettydefs file by
running /usr/lib/uucp/uugetty -c /etc/gettydefs. Note also that the
/etc/getty program does not "understand" 19200 baud, so you will need to
use EXTA as the baud rate if you want to run /etc/getty on a port.
Uugetty, however, does understand both 19200 or EXTA. The only
difference is that 19200 will appear as "unrecognized" if
/etc/getty -c is run on /etc/gettydefs.
Notwithstanding the net traffic, there is no reason to have ANYTHING in
the first gettydefs field for your modem except the baud rate. This
information is only used to initialize the port, and the second field is
executed before the "login:" message is output. Therefore, a system
attempting to log in will never "see" the first settings. Anything else
in the first field will accomplish nothing except to cause problems.
Note also that ISTRIP should be included. There have been some comments
on the net that this would cause 8-bit files to be truncated. This is
not a legitimate concern. Uucp traffic may pass through many machines,
over which you have no control. 8-bit data was not a consideration when
UNIX and uucp were developed. In addition, some "uucp" network hosts
are now not even UNIX machines since "uucp" protocols have been ported
to VMS, IBM, and other environments. The important lesson is that you
CANNOT rely on any uucp connection to pass 8-bit data. The proper
solution to this is to use uuencode or the "btoa" distributed with
compress to convert these files to 7-bit form for transfer over the
network. Thus, ISTRIP becomes an advantage because it helps avoid
problems when hosts which use different parity try to log in to your
system. This is particularly important if you communicate with IBM or
Honeywell mainframe sites.
[LBT's comments: The use of ISTRIP causes some problems when dealing
with protocols other than uucp that requires a full 8-bit data path.
I ran into this problem when using the xt-layers windowing protocol,
which requires this. Other protocols like slip may require this, as
well, so consider that when using the ISTRIP gettydefs flag]
/etc/killgetty:
while true
do
sleep 300
for line in "`ps -e|egrep uugetty`"
do
if [ "`echo $line|cut -c12-13`" -gt 1 ]
then
kill -9 "`echo $line|cut -c1-6`"
fi
done
done
This file may not be required in your installation. It exists because
my modem drops into 300bps mode if no handshake tone is detected. This
occurs when automated recordings, which dial every number in the
exchange, call for advertizing purposes. The result is that the modem
"hangs" thinking that it is receiving data, but the uugetty never
receives a newline, so it never invokes login and holds the line open
forever, preventing any login until the line is cleared manually. This
occurs whether or not the uugetty -r option is invoked. In fact, the -r
option causes most of the problems with trying to use uucp with uugetty.
Regardless of what Dialers strings are used, uugetty does not
consistently relinquish the line when the first attempt is made to dial
out. Thus, the attempt fails and causes problems for normal uucp
operation. The same problem occurs with Kermit or cu, but since there
is a human operator, a retry will overcome the problem.
The killgetty script tests the process table every 5 min for uugettys
and kills any uugetty that shows more than 1 min of cpu time.
Normally, uugetty sleeps until a login is requested, so it does not
accumulate cpu time. If the line is opened and a login occurs, uugetty
will exec login, so it will disappear from the process table. If
uugetty "hangs" as above, however, it will show >1min of cpu time and
will be killed. Init will then respawn uugetty on the port and it will
be reset. Thus, the maximum down time will be 5 min. These times may
be adjusted for your installation.
[LBT's comments: I have a similar situation when my EEPROM settings of
my Telebit Trailblazer aren't restored after the carrier is dropped
in certain abnormal conditions. Another solution would be to run this
out of a "cron" job every 15-20 minutes ...]
/etc/daemons/hfc:
/etc/hfc_ctl +/dev/tty000
This file is created by UA if you configure hardware flow control.
Under 3.51, HFC works, and should definitely be used in ANY serial
communications where the attached device can support it. There is NO
conflict between XON/XOFF and HFC. XON/XOFF can still be used so that
human terminal users can stop output with ^S. The entries in this file
enable RTS/CTS flow control between the modem and the UNIX-PC. Your
modem cable should be properly wired for this option: it should carry
lines 1-8 and 20 straight through from end-to-end with no jumpering.
The modem must also be configured. This is covered later.
Note that any executable file in /etc/daemons is run by the standard
/etc/rc during bootup. If you have modified your /etc/rc you will have
to make sure the above command is run for your port during bootup.
/usr/lib/uucp/Devices:
ACU tty000,M - 2400 hayes
Direct tty000,M - 2400 hayes_d
ACU ph1 ph1 1200 PC7300
This file defines the available ports to uucico (uucp) and cu. The ACU
entry defines a modem with dialout capability. The Direct entry is
necessary for cu to "directly" access the port to setup the nonvolatile
ram in the modem or to debug the connection. This is done using the
cu -dtty000 option. The (undocumented) ,M entry causes a O_NDELAY open
on the port so that DCD need not be asserted for the open() call to
succeed. The comments in Dialers are INCORRECT with regard to this
option. Dialers is not searched until AFTER the open() succeeds.
It is not desirable to "permanently" assert DCD, either by
modem options or by jumpering the cable. The problem is that your
system becomes unable to determine if the connection is broken or
someone hangs up without logging off. Thus, the next person dialing in
inherits the shell (and privileges) of the person who was last logged
in. You can imagine what might happen if you had been logged on as
root! This is also a potential cause of "hung" uucp connections that
eat up hundreds of dollars in long-distance bills. Can you say: "We're
getting BIG savings"? :-) The proper modem setup will be discussed
later.
/usr/lib/uucp/Dialers:
hayes =,-, "" \MATQ0E1\r\c OK\r \EATDT\T\r\c CONNECT \m\c
hayes_d =,-, "" \MATQ0E1\r\c OK\r
This file defines the commands necessary to cause each type of modem to
dial out properly. Note that neither this nor the Devices file have any
effect on INCOMING uucp or human login calls. The entries in this file
are critical to the effective use of uugetty, especially to avoid the
need for the -r option.
The entries above (see the internal comments in the Dialers file) cause
CLOCAL to be invoked. Then, the modem is commanded to return result
codes and locally echo its input. For a direct cu -ltty000 connection,
no further action is needed. For dialout, the CLOCAL mode is disabled
once the connection is completed (see comments below).
------------------------------------------------------------------------------
This completes the UNIX-PC configuration for HDB uucp. The modem is
configured as follows:
NOTE: This configuration is for a (FULLY!!!) Hayes-compatible 2400bps
modem. For this to work your modem MUST support the "reset on dropped
DTR" option. For the Trailblazer, you should consult the osu-cis
archives since this modem requires a somewhat more complex setup
process involving a "hidden" pushbutton to store the settings. The same
basic setup will work, but other options must also be enabled. These
are discussed in the Trailblazer setup guide on osu-cis.
Default Hayes setup string (assumes software control... see the manual
if your modem uses switches for configuration):
AT&FS0=2&D3&C1E0Q1&W
This tells your modem to:
&F: Restore all settings to factory defaults
S0=2: Autoanswer after 2 rings (note that this may be increased if you
use the line for voice calls, but be aware that a remote uucp
connection may time out before your system responds if you make
this value too big).
&D3: Causes modem to reset to default configuration upon loss of DTR
signal from UNIX-PC. This allows the configuration to be
changed in the Dialers script to allow echo and result codes.
The relevant commands (ATE1Q0) must also be output by any other
software which does outgoing dialing. Since you have the
sources for Kermit, this is not a problem for Kermit users.
Just insert the proper codes in the "wakeup" string. This
option also causes the modem to hang up whenever DTR is dropped
by the UNIX-PC. This is what allows the UNIX-PC to hang up a
call when HUPCL is enabled. The DTR line must not be jumpered
high. This is required to avoid "hung" uucp connections from
hosts which do not properly implement DTR. These hosts will
terminate the uucp protocol but will not hang up the modem. If
your machine has DTR asserted continuously, neither end will
hang up and the line will remain open. This option also allows
your system to hang up when HUPCL is enabled and a login is not
successfully completed within the time limit compiled into
login. This makes it more difficult for unauthorized users to
hack your system since they must keep redialing. See note on
HUPCL below.
&C1: Causes the modem to assert DCD only when a connection is
established and carrier is detected. This is essential to cause
your machine to hang up when the connection is lost (hangup).
Otherwise, whatever shell was in control at the time the line
was lost will remain active for the next user who dials in.
E0: Disables local echo by the modem. This prevents uugetty from
interpreting its own "login:" prompt as a user ID from the
remote user.
Q1: Disables result codes from the modem. This is necessary for
the same reason as E0 to prevent "OK" messages from the modem.
&W: Causes the present configuration to be written to the
nonvolatile RAM in the modem so it will be restored whenever
DTR is dropped by the UNIX-PC. This resets the configuration
following a dialout connection or power loss/reboot.
Note that there is a problem with uugetty and HUPCL. It seems that
uugetty does not always set HUPCL on incoming calls even if it is set in
the second /etc/gettydefs field. Thus the system does not disconnect on
logout but simply reissues the login: prompt. This can be overcome by
putting:
stty -clocal hupcl
before the final "trap" command in /etc/profile. Of course if you have
permanently connected terminals for which you wish CLOCAL to be
asserted, you will have to place the appropriate "if" or "case" syntax
to detect this condition.
-----------------------------------------------------------------------------
This uucp configuration allows first-time dialout without fail and also
presents the login: prompt as soon as carrier is detected from a remote
connection. This insures reliable uucp performance with any host
assuming that other factors (phone line quality, etc.) are satisfactory.
Note that some CCITT-compliant modems control the DSR (MR) signal,
asserting it only when entering communication protocol. Such
modems should be configured to keep DSR asserted whenever power is on.
Note also that the modem should be set to autobaud. The /etc/gettydefs
"cycle" arrangement to select the incoming baud rate is based on
obsolete modems which could not autobaud. All modern intelligent modems
autobaud. This means that the /etc/inittab entry should be set for the
highest speed of which the modem is capable. The actual data rate of
the modem will be set automatically by the autobaud feature. The RS232
connection will remain at the fast rate. The HFC lines on the port will
be used by the modem to prevent the UNIX-PC from overrunning the modem
buffers when communicating at a lower speed.
[LBT's comments: Beware on this one, HFC works, but only to a point.
The UNIX PC can't handle interrupts from the serial device fast enough,
especially at baud rates greater than or equal to 9600 baud. I still
use getty's (and uugetty's) capabilities of autobauding to the correct
baud rate. You will notice on a cable that is properly wired for HFC,
that at 9600 and 19200 baud you will loose characters, this is true
for modem connections (as in Telebit modems) and direct serial line
connections between 3B1s or other computers. I do see overrun when
fixing ("or locking") the baud rate of my Telebit Trailblazer during
uucico FAST connections.]
--
| Lenny Tropiano ICUS Software Systems lenny@icus.ICUS.COM |
| {ames,pacbell,decuac,sbcs,hombre,rayssd}!icus!lenny attmail!icus!lenny |
+------ ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 ------+