Xref: utzoo comp.unix.ultrix:931 comp.dcom.modems:3835 comp.sys.dec:1268
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cwjcc!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.unix.ultrix,comp.dcom.modems,comp.sys.dec
Subject: Re: Heard of this modem/vax/ultrix/whoknows problem?
Summary: continuous activity on RxD and TxD leads possible explanation
Message-ID: <1635@neoucom.UUCP>
Date: 16 May 89 11:19:28 GMT
References: <45025@peregrine.peregrine.com>
Distribution: na
Organization: Northeastern Ohio Universities College of Medicine
Lines: 41


This sounds like the classic getty-babble problem.  This happens
when the modem has command echoing enabled on a dial-in line.  When
the new getty forks, the modem gets some character, which it then
echos back to the host port because the modem is in command mode
after the call completes.

The simplest solution to the problem is to use the line for dial-in
only, and disable command echoing permanently via the dipswitch so
that when getty issues the prompt string, it won't be echoed by the
modem .. essentially the hardware analogy of ATE0Q1.  You need to
have Q1 set (via dipswitch too if possible) so that when the modem
answers that it doesnt send RING into getty, causing getty to send
back Password: before the carrier handshake has completed.. this
will cause the modem to hang-up the call.

It seems that even if you have ATE0Q1 set by hardware dispswitches,
most modems go into getty-babble on occasion anyway.  I deal with
that by running a script that looks for a lock file and/or port
being owned by root every 1/2 hour.  If the port is owned by root
and no lock file exists on the port, I kill the getty which in turn
forces the modem control leads (which you wired up, right?) low
which again in turn forces the modem into a sane state
(hopefully).  Getty babble is usually accompanied by a very high
load on the system due to the fact that the login process runs at a
high priority.

If you're using the port to dail out as well as in, your outgoing
chat script shoud issue a couple of ATZs separated by a /p to clear
the modem, then send it an ATE1Q0 to enable command echoing for the
duration of the current call.  It is a pain to try to use a port
for both dial-in and dial out without HoneyDanBer uucp.

Apologies if my diagnosis is wrong, but it sure sounds like
getty-babble.  I don't know about the DHV, but the DH and DZ
interfaces are a real pain in the neck because you one gives you
modem control, but no flow control, while the other has flow
control but no modem control.

Bill
wtm@impulse.UUCP