Troubleshooting

This section describes what may go wrong with your UUCP connection, and makes suggestions where to look for the error. However, the questions were compiled off the top of my head. There's much more that can go wrong.

In any case, enable debugging with -xall, and take a look at the output in Debug in the spool directory. It should help you to quickly recognize where the problem lies. Also, I have always found it helpful to turn on my modem's speaker when it didn't connect. With Hayes-compatible modems, this is accomplished by adding ``ATL1M1 OK'' to the modem chat in the dial file.

The first check always should 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.

uucico keeps saying ``Wrong time to call'': 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 which actually forbids calling at the current time. If no call schedule is given, uucico assumes that the system may never be called.

uucico complains that the site is already locked: This means that uucico detected 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. However, it's also likely that there's another uucico process sitting around that is trying to dial the remote system and got stuck in a chat script, etc. If this uucico process doesn't succeed in connecting to the remote system, kill it with a hangup signal, and remove any lock files it left lying around.

I can connect to the remote site, but the chat script fails: Look at the text you receive from the remote site. If it's garbled, this might be a speed-related problem. Otherwise, confirm if it really agrees with what your chat script expects. Remember, the chat script starts with an expect string. If you receive the login prompt, then 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.

My modem does not dial: If your modem doesn't indicate that the DTR line has been raised when uucico calls out, you possibly haven't given the right device to uucico. If your modem recognizes DTR, check with a terminal program that you can write to it. If this works, turn on echoing with E at the start of the modem chat. If it doesn't echo your commands during the modem chat, check if your line speed is too high or low for your modem. 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.

My modem tries to dial, but doesn't get out: Insert a delay into the phone number. This is especially useful when dialing out from a company's internal telephone net. For people in Europe, who usually dial pulse-tone, try touch-tone. In some countries, postal services have been upgrading their nets recently. Touch-tone sometimes helps.

I log file says I have extremely high packet loss rates: This looks like a speed problem. Maybe the link between computer and modem is too slow (remember to adapt it to the highest effective rate possible)? Or is it your hardware that is too slow to service interrupts in time? With a NSC-16550A chipset on your serial port, 38kbps are said to work reasonably well; however, without FIFOs (like 16450 chips), 9600 bps is the limit. Also, you should make sure hardware handshake is enabled on the serial line.

Another likely cause is that hardware handshake isn't enabled on the port. Taylor UUCP 1.04 has no provisions for turning on RTS/CTS handshake. You have to enable this explicitly from rc.serial using the following command:

I can log in, but handshake fails: Well, there can be a number of problems. The output in the log file should tell you a lot. Look at what protocols the remote site offers (It sends a string Pprotlist during the handshake). Maybe they don't have any in common (did you select any protocols in sys or port?).

If the remote system sends RLCK, there is a stale lockfile for you on the remote system. If it's not because you're already connected to the remote system on a different line, ask to have it removed.

If it sends RBADSEQ, the other site has conversation count checks enabled for you, but numbers didn't match. If it sends RLOGIN, you were not permitted to login under this id.