Chapter 12, Communications Over a Network

Modem Troubleshooting

 Before attempting to resolve modem problems, you should ensure that you have read the UUCP chapter in the SCO System Administration manual. This will give you the background information to UUCP that you require. You should then go through the following checklist:

  1. Check all the files you have changed on both the CMS and the remote system. Check that the entries in these files appear correct. The following list includes files you may have changed:

    In particular, make sure you have the correct password for the godoctor account on the remote machine, in the Systems file.

  2. Ensure the ports used by the modems are in a known state. You can turn off the modem and disable and then enable the modem ports and then turn the modem back on. A getty process should be running on the modem port that will be receiving the call. The modem receiving the call must be configured to answer the call. Refer to your modem documentation for details.

  3. Ensure that the dialer program is functioning correctly. This program can be run manually with full debugging trace. For example, when using the godialer program on /dev/tty1A, calling phone number 3654444 and trying to connect at 9600, run the command:

    This command will test that you have the correct setup for your modem in the /etc/default/godialer file. If you get an error from the modem, check this file, in particular the MDM_SETUP and MDM_DIALCMD entries.

  4. Try the cu command once the dialer program has been verified. It is part of the UUCP suite. Assuming the remote system name that you have set up in the Systems file is pluto and run the command:

    This command should dial the system pluto and give you a login prompt on the system. This will test part of the entry that you have made in the Systems file and also test that the remote machine has been correctly configured to answer calls. If the connection does fail, wait at least 30 seconds to allow started processes to terminate and the ports to be reset.

  5. Once you have a login prompt on the remote system, ensure that a godoctor account exists on this remote system. Also make sure that the process agent is running on this remote system. If not, you must start it with:

    Most problems can be resolved by following these five steps. If, however, you are still experiencing problems, further trace mechanisms are available. An understanding of how SCO Doctor for Networks connects to a remote system over a modem may be helpful. When SCO Doctor for Networks connects to a remote system, it runs a proxy process modemd. It is the job of this process to log into the remote host, start its counterpart on the remote system, modem, and then route communications over the modem link. Debugging trace from both modemd and modem can be saved to a file to help diagnose problems.

    On the CMS, the modemd process trace can be saved at level 1 through 9, with 1 being the least and 9 the greatest amount of trace output. Level 5 is usually sufficient to solve most problems. Control of the modemd trace level can be achieved by modifying the file /usr/lib/doctor/cf/doctor.cf. This file contains a comms paragraph with a modem_trace keyword which specifies the file name and trace level to use. The default is:

    which sends trace to the file /usr/spool/doctor/log/modemd.log:3 at trace level 3. You should exit SCO Doctor for Networks, change this keyword to suit your needs and try the connection again.

    Similarly, the trace level of the process modem, on the remote machine, is controlled by the modem_trace keyword in the comms paragraph in the /usr/lib/doctor/cf/agent.cf file on the remote system. Stop the agent process, modify this file, restart the agent process and try the connection again.