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.[1]
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.
