Olaf Kirch - Linux Network Administrator Guide, Second Edition

This section describes what may go wrong with your UUCP connection and makes location suggestions to fix the error. Although these problems are encountered on a regular basis, there is much more that can go wrong than what we have listed.

If you have a problem, enable debugging with -xall , and take a look at the output in Debug in the spool directory. The file should help you to quickly recognize the problem. It is often helpful to turn on the modem's speaker when it doesn't connect. With Hayes-compatible modems, you can turn on the speaker by adding ATL1M1 OK to the modem chat in the dial file.

The first check should always be whether all file permissions are set correctly. uucico should be setuid uucp , and all files in /usr/lib/uucp , /var/spool/uucp , and /var/spool/uucppublic should be owned by uucp . There are also some hidden files in the spool directory which must be owned by uucp as well. [104] That is, files with names beginning with a dot. Such files aren't normally displayed by the ls command.

When you're sure you have the permissions of all files set correctly, and you're still experiencing problems, you can then begin to take error messages more literally. We'll now look at some of the more common errors and problems.

This probably means that in the system entry in sys , you didn't specify a time command that details when the remote system may be called, or you gave one that actually forbids calling at the current time. If no call schedule is given, uucico assumes the system can never be called.

This means that uucico detects a lock file for the remote system in /var/spool/uucp . The lock file may be from an earlier call to the system that crashed or was killed. Another possible explanation is that there's another uucico process sitting around that is trying to dial the remote system and has gotten stuck in a chat script, or stalled for some other reason.

To correct this error, kill all uucico processes open for the site with a hangup signal, and remove all lock files that they have left lying around.

Look at the text you receive from the remote site. If it's garbled, you might have a speed-related problem. Otherwise, confirm that it really agrees with what your chat script expects. Remember, the chat script starts with an expect string. If you receive the login prompt and send your name, but never get the password prompt, insert some delays before sending it, or even in between the letters. You might be too fast for your modem.

If your modem doesn't indicate that the DTR line has been raised when uucico calls out, you might not have given the right device to uucico. If your modem recognizes DTR, check with a terminal program that you can write to the modem. If this works, turn on echoing with \E at the start of the modem chat. If the modem doesn't echo your commands during the modem chat, check if your line speed is too high or low. If you see the echo, check if you have disabled modem responses or set them to number codes. Verify that the chat script itself is correct. Remember that you have to write two backslashes to send one to the modem.

Insert a delay into the phone number, especially if you have to dial a special sequence to gain an outside line from a corporate telephone network. Make sure you are using the correct dial type, as some telephone networks support only one type of dialing. Additionally, double check the telephone number to make sure it's correct.

Well, there can be a number of problems in this situation. The output in the log file should tell you a lot. Look at what protocols the remote site offers (it sends a string P protlist during the handshake). For the handshake to succeed, both ends must support at least one common protocol, so check that they do.

If the remote system sends RLCK, there is a stale lockfile for you on the remote system already connected to the remote system on a different line. Otherwise, ask the remote system administrator to remove the file.

If the remote system sends RBADSEQ, it has conversation count checks enabled for you, but the numbers didn't match. If it sends RLOGIN, you were not permitted to log in under this ID.

When compiling the UUCP suite to use Taylor-style logging, you have only three global log files, all of which reside in the spool directory. The main log file is named Log and contains all the information about established connections and transferred files. A typical excerpt looks like this (after a little reformatting to make it fit the page):

uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3)

uucico pablo - (1994-05-28 17:15:39.25 539) Login successful

uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful

(protocol 'g' packet size 1024 window 7)

uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj

uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai

uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at

uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as

uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2

uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1

uucico pablo - (1994-05-28 17:15:59.05 539) Protocol 'g' packets: sent 15,

resent 0, received 32

uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26 seconds)

uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai

(rmail okir)

uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as

(rmail okir)

uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1

(rmail okir)

The next important log file is Stats , which lists file transfer statistics. The section of Stats corresponding to the above transfer looks like this (again, the lines have been split to fit the page):

postmaster pablo (1994-05-28 17:15:44.78)

received 1714 bytes in 1.802 seconds (951 bytes/)

postmaster pablo (1994-05-28 17:15:46.66)

received 57 bytes in 0.634 seconds (89 bytes/)

postmaster pablo (1994-05-28 17:15:49.91)

received 1898 bytes in 1.599 seconds (1186 bytes/)

postmaster pablo (1994-05-28 17:15:51.67)

received 65 bytes in 0.555 seconds (117 bytes/)

postmaster pablo (1994-05-28 17:15:55.71)

received 3217 bytes in 2.254 seconds (1427 bytes/)

postmaster pablo (1994-05-28 17:15:57.31)

received 65 bytes in 0.590 seconds (110 bytes/)

The third file is Debug . Debugging information is written here. If you use debugging, make sure this file has protection mode 600. Depending on the debug mode you select, it may contain the login and password you use to connect to the remote system.