|
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 authors 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.
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 doesnt 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 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 isnt 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.
Sequence | Description |
---|---|
\p | Pause (approximately 1/41/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 |