Modem troubleshooting

When encountering problems when you use a modem with your computer, keep in mind the following points.

Some modems are case-sensitive. Use uppercase letters for the AT commands.
In normal operation, it is preferable for the modem to reset when the DTR is dropped (&D3 setting). When the modem is being set up for the first time, however, it is advisable not to have the modem reset if the DTR is dropped (&D2 setting). If the modem resets itself, all programmed settings that are not saved in the modem's memory will be lost.
Not having the modem reset also protects changes when &C1 is set. Changing the Carrier Detect status might cause the carrier detect line to toggle some modems, which causes the cu command to drop the line. You might want to set up the modem to &D3 after the final setup is made.
Although the commands given in this topic collection are standard for most Hayes-compatible modems, there is no guarantee that they are standard for your modem. Compare the commands with your modem documentation before proceeding.

A convenient way to debug any modem problem is to remove the modem and attach an ASCII terminal (with an interposer or null modem) to the same port and cabling as the modem. Set up the terminal with the same line speed, bits per character, and parity as the modem. If the port is enabled for login, a login herald must be displayed on the screen. If the herald is displayed on the terminal screen, then the problem is quickly isolated to the modem configuration.

The following tips help you in isolating problems that are associated with modem connections:

Table 1. Modem problems and solutions
Problem	Resolution
Respawning too rapidly	The getty program is respawned by init.
Messages on console or errpt	If init sees that it has to respawn any program more that five times in 225 seconds, it will display the message on the console and not respawn it for a period of time. The solution is to find out why getty is dying. There may be several causes: Incorrect modem settings, usually as a result of having CD strapped high on the modem or cabling and also having either "echo" or "command response" turned on. (CD can also be assumed high by adding clocal in the runmodes and/or logmodes in the port configuration or also forced on the 128 port.) Toggling of the CD signal. The getty process will die every time CD is toggled from an on to off state. (This action could be caused by a number of reasons. Be sure to verify that the cable is properly shielded. Logging in and out several times in rapid succession can cause this.)
No login prompt displayed after connection to modem	Make sure getty is running on the port. If it is, verify that the carrier detect connection to modem signal is being raised after the remote side has connected to the modem. If CD is being properly asserted, then verify the modem is connected to the right port. If you still do not see login, then attach a terminal with interposer to the cable in place of the modem and verify that a login prompt does appear. If you still don't see a prompt, try to echo characters to the terminal screen to verify the cable and hardware are functioning properly.
When a remote modem connects, it immediately disconnects	Verify that the modem is talking to the server at the same speed at which the server is listening to the modem. Try different baud rates for the tty, or program the modem to lock DTE speed to match the speed of the tty port. Verify that the modem or port is not keeping the carrier detect signal high or that the port is already being used by another process.
Getting garbage characters instead of a login prompt	This is due to a difference in protocols. Be sure to verify that the modem and the tty port agree on the same parity, baud rate, flow control, and character size.
Sometimes, after a successful session, no one is able to login	It might be that the modem does not reset after disconnect. See the modem manual to see how the modem can be set to reset after an on to off DTR transition.
Receiver buffer overruns in errpt	The UART chip buffer is being overrun. Lower the value of the receive trigger in SMIT for the tty. This solution is only valid for the native, 8- or 16-port asynchronous adapters. Verify that the modem and tty port are using the same flow control.
ttyhog errors in errpt	Modem and tty either do not agree on flow control, or no flow control is taking place.