[net.micro.att] Help needed with Penril auto-answer/auto-dial modems on 3b2

pat@pyuxqq.UUCP (Pat M. Iurilli) (06/28/85)

Does anyone out there know why, or how to correct the following problem when
using a Penril auto-dial/auto-answer modem with the Basic Networking
software package on the 3b2?  After the modem hangs up, regardless if
a successful connection was made or not, the modem oscillates on the
phone line.  What I mean by this is that it picks up the line, gets a
dial tone for an instant and hangs up.  It does this several times
with a few second interval several times before stopping and freeing
the line so it can again be used.  I don't know if it's the uucp/cu
software, the 3b2 itself, or the Penril.  Anyone have any ideas?  If
it's any help, i've  tried different phone lines and different
Penrils. (all 8216 AD1200/300 Penrils)  Thanks in advance.
Pat Iurilli  Bell Communications Research  Piscataway, NJ
{allegra, ihnp4}!pyuxqq!pat

psc@lzwi.UUCP (Paul S. R. Chisholm) (07/03/85)

< I can use my magic to change the color to red -- but I don't do windows. >

In article <729@pyuxqq.UUCP>, pat@pyuxqq.UUCP (Pat M. Iurilli) writes:
> Does anyone out there know why, or how to correct the following problem when
> using a Penril auto-dial/auto-answer modem with the Basic Networking
> software package on the 3b2?  After the modem hangs up, regardless if
> a successful connection was made or not, the modem oscillates on the
> phone line.  What I mean by this is that it picks up the line, gets a
> dial tone for an instant and hangs up.  It does this several times
> with a few second interval several times before stopping and freeing
> the line so it can again be used.
> Pat Iurilli  Bell Communications Research  Piscataway, NJ
> {allegra, ihnp4}!pyuxqq!pat

A port can be incoming, outgoing, or bidirectional.  For some reason
(possibly related to the fact that the Penril is a smart modem, and
keeps DCD up all the time, so open() succeeds even when no call is
incoming), specifiying incoming makes the getty constantly "pick up"
the phone.  If you specify bidirectional instead, uugetty is run on
the line.  Uugetty not only knows how to step out of the way of
outgoing calls, but is a little bit smarter about smart modems.
-- 
       -Paul S. R. Chisholm       The above opinions are my own,
       {pegasus,vax135}!lzwi!psc  not necessarily those of any
       {mtgzz,ihnp4}!lznv!psc     telecommunications company.
       "It must be fast, and it must be red, and it must have windows."

heiby@cuae2.UUCP (Ron Heiby) (07/05/85)

In article <186@lzwi.UUCP> psc@lzwi.UUCP (Paul S. R. Chisholm) writes:
>If you specify bidirectional instead, uugetty is run on
>the line.  Uugetty not only knows how to step out of the way of
>outgoing calls, but is a little bit smarter about smart modems.

The two main things about uugetty that makes it different from ordinary
getty is that A) it conforms to the same locking protocol that cu and
uucico conform to, and B) it doesn't "wake up" until it receives a character
(like a CR).  This means that someone (or a uucico) login in must send
a character before they will see a "login:" prompt.  It also means that
if characters are sent from the modem when a local uucico has ended and
the line disconnects, uugetty will see that there are incoming characters
and no current lock on the line, so it will "wake up".  I believe that
this is why the uugetty is supposed to be specified with a 60 second
timeout and why the documentation recommends not trying to access that
port for at least 60 seconds.  The key words are, "little bit smarter."

Part of the above is conjecture, although I believe it to be substantially
correct.  In short, don't worry about it.
-- 
Ron Heiby	heiby@cuae2.UUCP	(via ihnp4)
AT&T-IS, /app/eng, Lisle, IL	(312) 810-6109