OBM Auto-answer disabling

[Bill Mayhew]

Ah,  the old mysterious reappearing getty trick, chief.

By th way, OBM == On Board Modem, for the Unix PC, for those you
you were reading this and wondered what the heck we were talking
about.

The 3.51 O/S software is rigged with the assumption that if you
want to use the OBM at all, then you want the OBM to both make and
receive calls.  Not a terribly good assumption, if you ask me.  For
instance, I use a Trailblazer external modem ot handle all the uucp
traffic for my mahcine on a dedicated data phone line.  The OBM is
a pretty lousy modem by today's standards.  I have a $100 Radio
Shark modem that seems to have an adaptive equalizer that handles
poor connections where to OBM is unable to maintain a reliable
connection.

Now, I would like to keep the OBM around for emergnecy dail-out use
for on my voice line at times when the data line is busy.  I don't
want the OBM to automatically answer; I'd rather have Voice Power
or myself handle human calls.

Much of the software that uses OBM calls the programs
/usr/bin/geton.sh and /usr/bin/getoff.sh.  As you might guess, the
first is a shell program that calls /usr/bin/setgetty to enable a
getty, while the latter diables the getty.  Setgetty edits the
/etc/inittab file (A real no-no in my book!) and and calls init to
mark re-read the inittab.

My quickie fix was to patch geton.sh to that it did not really call
setgetty.  Geton.sh has to appear to work, or software such as cu
and uucico will fail.  Some bogosities, such as /etc/ph seem to man
handle inittab on their own, so there isn't much you can do to stop
getty being reenabled unless you want to patch bianries.

One thing you can do is to run /usr/bin/setgetty ph1 0 from your
crontab on a regular basis to assue that any offending getties that
slip through your wall of defense get squished out.  Of course, you
should use ph0 in place of ph1 if the example above, depending upon
your configuration.  The Usenet collective wisdom is that line 0
should be voice, if possible, and line 1 should be data only, if
possible.  I don't recall the origin of the folklore now, but it
has been around several times.

Perhaps the most pragmatic solution is to get a ring defeating
netowrk from a telephone supply vendor.  I imagine that such a
network has a varistor and a couple of diodes so that the downstream
device doesn't get sufficient ring voltage to trigger, yet can
still complete the loop when going off hook.  Heaven only knows; an
AT&T phone Center might even have one!?...

As far as surviving a call-wainting tone blitz, the solution is
central-office dependent.  In some areas, dialing *70 and *71 can
be used to control call waiting.  It happens that where I live, it
is impossible to defeat call waiting.  Even if you program your own
modem to have a sufficeintly long loss-of-carrier delay, the other
side will have problems, because of the blanking while call waiting
tones are presented to your side of the connection.  The only real
effective solution is to have a dedicated data line.  I'm glad that
I have two lines, and feel that it is well worth the extra $20 US
per month that it costs.

==Bill==
-- 

Bill Mayhew  Northeastern Ohio Universities College of Medicine
Rootstown, OH  44272-9995  USA    phone: 216-325-2511
wtm at uhura.neoucom.edu   ....!uunet!aablue!neoucom!wtm