Problems dialing in

You may experience one of the following problems on dialing out:

• ``Modem does not answer the phone''

• ``NO DEVICES AVAILABLE message''

• ``Garbage or loose cable''

• ``Modem answers, but no login prompt is displayed''

• ``Screen displays a series of login prompts''

• ``System displays meaningless characters''

Modem does not answer the phone

If the modem does not answer the phone:

1. Verify that the modem control port is enabled. To enable the modem port, enter the following commands:
   
   disable /dev/tty1a
   enable /dev/tty1A

2. Verify that the modem is configured to auto-answer. Check your modem switches. If the modem has a ``Direct'' entry in /usr/lib/uucp/Devices (for the /dev/tty1A device, for example) enter:
   
   cu -ltty1A dir

   Then, use the ATS0=1 command to tell the modem to answer the phone on the first ring. (Remember to enter AT&W to save modem settings.)
   

3. Verify that the DTR (Data Terminal Ready) line is connected from the computer to the modem. Make sure that pin 20 is connected. Pins 2, 3, 7, 8, and 20 are required for modem communication.

4. Make certain the ACU entry for this modem in the Devices file precedes any ``Direct'' entries for the port or the non-modem control counterpart.

Modem answers, but hangs up

If the modem answers, but hangs up immediately upon connection:

1. If the modem is set to auto-answer and to detect DTR, check to see that the DTR line is asserted.

2. Verify that the modem control port is enabled:
   
   disable /dev/tty1a
   enable /dev/tty1A

3. Verify that the cable is correct. If you are using a straight-through cable with at least pins 2, 3, 7, 8 and 20 connected, verify that pin 20 (DTR) is properly connected.

4. Check to see if the modems have data compression or error correction modes set. After a connection is established, modems that support special error correction or compression protocols attempt to negotiate which of these protocols to use. If the other modem is programmed not to use any of these modes (or does not support them), it may misinterpret this negotiation as actual user input. In general, modes such as MNP4 or v.42bis should only be enabled when connecting with a modem with the same modes enabled. Check the documentation for your modem.

Garbage or loose cable

If the console displays a message like

   Garbage or loose cable on /dev/tty1A, port shut down

1. Verify that your modem is not set to echo back data or send command responses. If the modem is not set up this way, it may be sending a RING signal to indicate that the phone you are calling is ringing. Because the CD signal is not active, the serial driver interprets this as random data on the serial line. The appropriate AT-compatible modem command is ATE0Q1.

2. If you have an internal modem and the above options do not eliminate the error message, your modem may be incompatible. Contact the manufacturer to see if a fix is available. If no fix is available, you may need to replace your modem with a standard AT-compatible external modem.

Modem answers, but no login prompt is displayed

If the modem answers, but does not display a login prompt:

1. Verify that the CD line is being asserted by the modem after the modem has answered the phone. Check the switches on your modem or, if your modem is AT-compatible, use the AT&C1 command. (Remember to enter AT&W to save modem settings.)

2. Make sure that the port is enabled. Enable the port by entering the following command sequence:
   
   disable /dev/tty1A
   enable /dev/tty1A

3. Verify that the entry for the incoming line in the /etc/inittab file is correct. The entry defines the characteristics of the getty process that monitors the modem control port. The final argument to the getty command is a single letter or digit that references an entry in the /etc/gettydefs file. This defines a range of speeds, parity, number of stop bits, and so on, that can be used on the line.

   Refer to ``Serial port speeds, line-mode labels, and UART limitations'' in ``Configuring a serial port'' for information about the limitations on the speed of a serial port that are imposed by the UART (universal asynchronous receiver/transmitter) chip that controls it.

   For details of the capabilities of ports on intelligent serial boards that use third-party device drivers, refer to the manufacturer's documentation.

   For example, the following entry in inittab spawns a getty process to allow incoming connections at 9600bps on the modem control port /dev/tty1A:

   Se2A:2:off:/etc/getty -t60 tty1A m
   

   For more information on the /etc/inittab file and the various control codes, see the init(M), inittab(F), getty(M), and gettydefs(F) manual pages.

   ---

   NOTE: Each time the kernel is relinked (when a driver is added or a tunable parameter is changed), /etc/inittab is reconstructed from the entries found in /etc/conf/init.d/sio.

   Duplicate any changes you make to /etc/inittab in /etc/conf/init.d/sio.

   ---

Screen displays a series of login prompts

If the screen scrolls uncontrollably when you log in, usually displaying a series of login prompts, verify that only the modem device is enabled. If the non-modem device is enabled, disable it, for example:

disable /dev/tty1a

System displays meaningless characters

If the system displays the login prompt, but no password prompt, or meaningless characters are displayed after the login prompt, verify that the line settings are correct:

1. Determine the serial line settings on the system that you are calling. The standard settings that cu uses are 8 data bits, one stop bit, and no parity.

   • if the remote system uses even parity, use the -e option with cu. For UUCP, precede the login script defined for the system in /usr/lib/uucp/Systems with the PEVEN keyword

   • if the remote system uses odd parity, use the -o option with cu. For UUCP, precede the login script defined for the system in /usr/lib/uucp/Systems with the PODD keyword

   • if the remote system uses 7-bit no parity, use the -oe option with cu
   
   

2. If you are dialing into a UNIX system, check the /etc/inittab file on the remote system to verify that the ``pointer'' into the /etc/gettydefs file is correct. The serial line characteristics may not match between the stty settings defined in the third field of the selected gettydefs entry. Change the setup for the port to 8 data bits, one stop bit, and no parity.

   The entry should similar to the following:

   n # B19200  HUPCL # B19200  CS8 SANE HUPCL TAB3 IXANY #\r\nlogin: # n