Modem login woes

[Michael J. Sabal]

I have two modems connected to an RJ-45 MUX. HP 700/70 terminals connected to the MUX can log in fine. The two modem ports are configured at 9600bps, 8N1. Queries to the modems using cu tell me the modems are configured the same way. When I call the modems for an inbound connection to the server (running HP-UX 10.20), the modems answer and handshake, but never produce a valid login prompt no matter how many times is pressed. uugetty is alive and waiting on the ports (as indicated by ps -ef | grep 'ttyd2'). The remote workstation's terminal settings were confirmed to be also set at 9600 8-N-1 with VT100 emulation. With the same settings, one modem port produced garbage characters, and the other modem port returned nothing to the remote workstation.

Any suggestions on what to try next?

[Darren Prior]

Hi Michael,

There are many variables when it comes to problems with modems so I'll try to make my advice generic. I've only used MultiTech modems, there are some issues with cabling and USR modems that I've heard about so you may wish to search the knowledge database if you're using them.

Firstly, before you dial up the modem check what tty is listed for the uugetty on the incoming machine. It should show a ? rather than ttydwhatever at this stage. If it doesn't show a ? then it suggests that CD (carrier detect) is present (could be a faulty modem, or incorrect modem config.)

If you've passed that test then dial the modem's number - when it's answered, hit return and check the uugetty's tty again - it should now be the ttydwhatever, else there could be a cabling issue or the modem isn't raising CD.

Next try killing the uugetty - does the modem connection get dropped? Not dropping the line suggests that the modem is ignoring DTR.

If the connection was dropped, try dialling the modem again - watch the incoming modem's TD light; if it doesn't flicker after you've hit return (where it should be sending the login prompt) then it's most likely to be:

1) getty config - this is controlled by inittab and gettydefs. getty -c can do some basic syntax checking for gettydefs (check the getty(1M) man page) but if in doubt copy in the /usr/newconfig and put your entry in again preferably not at the very end of the file as gettydefs is fidgety about the end of the file. Also ensure that you have one blank line above and below your entry.

2) cabling problem - check http://docs.hp.com for the documentation and cabling info for your mux.

3) defective modem

best regards,

Darren.

[Michael J. Sabal]

Thanks for your suggestions. All the tests passed, except for one thing. It seems that on at least on of the ports, the CD light stays on, but then when the remote workstations presses , the CD light goes off before the is received by uugetty. The login prompt is never sent.

On the other port, everything acts like it is connected fine and the login prompt is being transmitted, but it seems like there's a bitrate or parity mismatch. Unfortunately, I don't know what the mismatch might be, since everything I know where to check on both ends shows 8-N-1.

If swapped out about 5 modems with no change in results. It seems to be a port configuration problem, but I have no idea where to configure such a thing.

As for the hardware cabling; these ports, cables, and such were working well once upon a time. Another administrator and some consultants (who no longer work with us) made a number of configuration changes to "fix" a predictive support issue, including patches and utilities. After talking to a number of users, it seems that may be when the trouble started.

Next steps?

[John Dvorchak]

My 2 cents worth. On the modem where you get a CD light and as soon as a carriage return is sent it drops CD and hangs up. That modem is set to echo locally back to the server. What I think is happening is that the C/R is sent the server responds with Login: and the modem echo's that back to the server so the server thinks that Login: is the ID then it responds with Password: and the modem again echo's that back so now you have the login getty thinking it is blown userID and password. It does this 3 times real fast, assumes someone is trying to hack it and then shuts down the login and resets the modem by cycling getty. Try CU to the modem and check it for local echo.
Good luck

[John Dvorchak]

Second modem problem, be sure and check that both modems are set to async. I had this problem once and the modem was set to "sync" but would dial and connect but then garble. Usually restoring the factory defaults is a good place to start with the modems.