Xref: utzoo comp.dcom.modems:1302 comp.sys.att:2305 comp.unix.questions:5339
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!uvaarpa!virginia!scl
From: scl@virginia.acc.virginia.edu (Steve Losen)
Newsgroups: comp.dcom.modems,comp.sys.att,comp.unix.questions
Subject: Re: GETTYDEFS, etc. (babbling getty)
Message-ID: <564@virginia.acc.virginia.edu>
Date: 22 Jan 88 15:50:48 GMT
References: <142@mccc.UUCP>
Reply-To: scl@virginia.EDU
Organization: University of Va., Charlottesville, VA
Lines: 52

In article <142@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes:
>
>From time to time, a remote user does something that causes a modem to lock 
>up.  When locked up, its RD/SD lights flash continuously and the OH light
>is on.  Also, an incoming call to that modem gets NO ANSWER.  A call to the
>other modem gets answered, but the response is slow, jerk, and characters
>are frequently not received.

This is the classic "babbling getty syndrome"

The problem is that the getty is sending a login: prompt to the modem while
the modem is in command mode and the modem is echoing these characters back.
Getty then thinks that someone is trying to login, sends the password prompt
and this promptly gets echoed back.  Then getty sends error messages and these
get echoed back as well.  Some characters that the modem echoes are re-echoed
back to the modem by the 3b2.  This accounts for the SD/RD problem.  The resulting
massive explosion of serial I/O puts such a strain on the kernel that I/O on
other ports is seriously impaired.

Be sure that the modem switches are set so that carrier detect follows
the state of the phone line.  That is, after the user breaks the
phone connection, carrier detect should drop.  This will cause the current
getty to exit with SIGHUP and prevent the next getty from opening the tty port
to the modem until another call has come in.  Unfortunately, this will
probably also prevent cu and uucico from opening the modem so you will not
be able to dialout on this modem.

Also set the HUPCL flag /etc/gettydefs.  This will cause unix to drop DTR to
the modem (and the modem hangs up the phone) when someone logs off.  Unfortunately
HUPCL means "hang up on *last* close", so if someone leaves a process running in
background that still has the tty open, unix won't drop DTR.

If you are using the modem for dialout, for heaven's sake turn off that getty!

If you want to use the modem for both dialout and dialin good luck.  It is
possible, but it is not at all trivial to do.  You have to use uugetty
instead of getty and do a lot of playing around with your modem until you
hit upon the correct configuration.  Basically, uugetty opens the tty line
and does a read before typing any prompt.  When the read completes (presumably
after someone has connected and hit a CR) uugetty checks for a lockfile to
see of some other process (such as uucico or cu) has locked the line.  If
the line is clear, uugetty logs in the user.  If uugetty sees a lockfile,
it goes to sleep (it can't exit or init will spawn another uugetty)
and periodically checks the lockfile.  Once the uucico or cu is done,
uugetty exits and init spawns another one.

It is sad to say, but the simplest solution to the dialin/out problem is
to reserve some of your modems for dialout only and turn off getty's to
those lines.  The rest can be used for dial in.
-- 
Steve Losen     scl@virginia.edu
University of Virginia Academic Computing Center