HostedDB - Dedicated UNIX Servers

-->
Internet Security Professional Reference:Using UUCP
Previous Table of Contents Next


This entry defines a device named TBIT, which is accessed through /dev/tty17 using the TBIT dialer program. This entry allows any connect speed requested in the Systems file.

bugs         tty21     -         9600     direct

This entry defines a device named bugs, which is a name of one of the machines in the author’s local UUCP network. The dialer program is direct, indicating that this is a direct connection, and connections are done at 9600 baud only. It is common for the device in a dedicated connection to be named the same as the remote system in order to establish system specific values, or enable certain permissions.

TCP         TCP,e    -        Any        TCP        540

The preceding entry defines a device used for TCP/IP connections using the “e” protocol. There is no dialer port, and any speed can be used. The TCP in the dialer field indicates that this is a TCP connection to be made on the port specified in the token field, TCP port 540.

Now that the entry in the Devices file has been created, file ownership must be discussed. UUCP requires that the Device files it uses are owned by UUCP, and have a group of UUCP. Failure to do this will result in errors about not being able to access the device in question.

Evaluating the owner and group is done using the ls command. If the group owner for the device, such as /dev/tty17, is not set to UUCP, it is possible for connection problems with the device to occur.

Testing the Connection

Before you read about setting up the Systems file, you can test the existing connection using the cu command. Assume you are using the following device definition in the Devices file:

bugs          tty21     -         9600     direct
Direct        tty21     -         9600     direct

To test the connection to see if it is live, the use of cu is required, as illustrated in the following output (comments are marked in [ ]):

chare@unilabs> cu -l tty21
Connected           [The Connected prompt indicates that we have
                    connected to the DEVICE, not necessarily to the
                    remote system.]
<RETURN>            [ Get the remote hosts attention]
login: anon         [ login ]
Welcome to Unilabs Research

CONNECTED TO: bugs.unilabs.org

anon@bugs>
anon@bugs> date
Tue Dec 29 21:00:11 EST 1992
anon@bugs> exit

bugs!login:
~[unilabs].           [ To disconnect from the remote system after logging
                    out, use the ~. command of cu to terminate the
                    connection.]
Disconnected          [ The connection to the device is closed.]
chare@unilabs>

If no communication is established with the remote machine, you should debug the actual connection by verifying the media used to make the connection. In the preceding example, debugging involves making sure the cable is plugged in at both ends, that the other machine is running, and the port is enabled for login. If that doesn’t correct the problem, then it may be a communication issue regarding the cable. For example, the cable does not have enough RS-232 signals to establish communication between the modem and the computer system. Whatever the reason, when the connection is verified as working, you can continue with the setup of the UUCP files.

The Dialers File

The Dialers file contains a series of characters that are sent to a modem to initiate a phone call. In some UUCP implementations, such as SCO Unix, dialer programs may also be a binary program. SCO also provides a mechanism that uses a binary program and a custom dialer script to communicate with the modem. It is more common, however, to see dialer scripts developed and implemented through the Dialers file. Each entry in the Dialers file has three parts:

Type     801     Chat Script
hayes    =,-,    “” \dAT\r\c OK\r ATL1M1\r\c OK\r \EATDT,,\T\r\c CONNECT
intacu   ==-,    “” \K\dEN\dAT\r\c: Q\c + \021\c “” \pEN\c + \0041 +
AT\r\c: D\T\r\c COMPLETE
TBIT     =W-,    “” ATZ\r\c OK\r A\pA\pA\pT OK ATQ4E0X0 OK\r
ATS53=1S48=1S50=255S51=255S101=0S111=30\r\c OK\r ATDT\T\r\c CONNECT

The Type field defines the type of device. For example, the hayes entry defines a Hayes 2400 baud modem; intacu defines a 1200 baud internal modem; and TBIT defines a Telebit Trailblazer Plus. The second field provides the translations for the 801 dialer codes. This field isn’t used anymore, and is typically filled with =,-,. The third field is a chat script that works similarly to the chat script in the Systems file, discussed later in this chapter. The chat script is a series of expect-send pairs, meaning expect this, and when it is received, send this. The special characters, preceded with a backslash (\), are defined in table 3.3.

Table 3.3
Dialer File Special Characters

Sequence Description

\p Pause (approximately 1/4—1/2-second delay)
\d Delay (2 seconds)
\D Phone number/token
\T Phone number with Dialcodes and character translation
\N Insert a Null byte
\K Insert a break
\E Turn on echo checking (for slow devices)
\e Turn off echo checking
\r Insert a Carriage return
\c Do not insert a new-line
\n Send new-line
\nnn Send octal number

To see how this dialer script functions, look at the operation of the Hayes dialer entry.

Expect          Send
“” (nothing)    \dAT\r\c (delay, send AT)
OK\r            ATL1M1\r\c
OK\r            \EATDT,,\T\r\c
CONNECT

This chat script is being used to communicate and configure the modem prior to making the call. In the 4 send sequence, when the modem is sent the string “\EATDT,,\T\r\c”, it is being told to turn on echo, and to dial the phone number. The dialer token \T causes the phone number to be put in place when the script is actually used.


Previous Table of Contents Next