need help with modem, the saga continues

[Mike Borza]

In article <11322 at quacky.mips.COM> menna at mips.COM (Randy Menna) writes:
        [lots of useful info about his problem and config deleted...]

This seems to be a problem in the original V/386 port.  I'm using
ISC 386/ix (V1.0.6), and have also spent an inordinate amount of
time trying to solve the same problem.  Surely someone out there
is using the same modem for dial-ins and dial-outs for both uucp and
cu (maybe even kermit and others...) under one of the AT&T derived ports.
I'd be interested in hearing from them.  To date I've never been able
to dial in to my V/386 system more than once without resetting the modem.
On my SV/AT system at home, I have no such problem using the tty0/m0/M0
combination to duplicate what should already be built into the ASY
driver under V/386 (according to the docs... see below).

>
>	command echo off		( ATE0 )
>	track state of data carrier	( &C1 )
>	  from remote modem, "on"
>	  condition indicates presence
>	  of a carrier

The software vendor I bought 386/ix from has been trying to track this
problem down with ISC, who has been rather unresponsive to date.  There
are a number of problems which may be either documentation errors
or actual driver problems.  For example, the AT&T _UNIX_System_V/386_
_System_Administrators_Reference_Manual_ man entry for ASY(7) states
"If the port was opened with the modem control bit present...modem
control will be enabled.  If enabled the driver will wait in open until
Data Carrier Detect is present."  This statement is reiterated in
the ISC supplied documentation.  The modem control bit is enabled thus:
"The low-order 4 bits (bits 0-3) of the minor device correspond to the
asynchronous port. Bit 4 enables modem control on the port".  As
supplied by ISC, there is no minor device with bit 4 enabled, so
I tried making one, but the behaviour was identical to that observed
on /dev/tty00.  Interestingly, the cabling suggested from serial
port to modem is not a straight through cable, but as follows:

      modem        computer
        2             2
        3             3
        7             7
      4,5,6,20        8           <======
                    4,5,6,20      <======

According to this, DCD on the modem end is ignored altogether, and
the driver is looking for activity on DSR to indicate a login attempt.
This indicates that someone has hacked up the ASY driver, possibly
breaking it in the attempt.  Randy's experience is so similar
to my own that it appears to be in a common ancestor, i.e. either
ISC or AT&T is responsible.

>	assumes initailzation state	( &D3 )
>	  when detecting an on to off
>	  DTR transition. (current settings
>	  are over written with ones in
>	  nvram)
>

I tried this also, but it appears that once DTR goes low, it stays
that way indefinitely.  My modem doesn't seem to do anything until
it sees DTR high again, so you know what happens then.  This is why
I've never been able to get more than one login through.

>THE PROBLEMS I'M STILL HAVING:
>
>    When I have the getty spawned, it appears that it still talks
>    to the modem incescently.  The tx/rx lights on the front panel
>    of the modem flicker.  The cd (carrier detect) light never comes
>    on.

I've had this problem with both getty and uugetty.  Cu'ing out is
also fun, because you can sometimes get your own login prompt back.
It all gets pretty weird after that.

>    "init: process respawning too rapidly, check for possible errors:
>    /etc/getty -h -t 30 ttyM00 2400"
uh, huh...

>
>    The modem does not even answer the phone now, whereas before it used
>    to answer but not talk.  I am getting a new modem (same model) on 
>    wednesday, in case due to some chance that I have a hardware problem
>    with the modem.  
Something with your modem commands twigged.  Are you using a Packard Bell
modem by any chance?  It's not clear to me from their doc's what commands
are extensions to the Hayes command set. If this is the case, we may
both be seeing the same problem.
>
>    At this point I'm stuck, I thought that I understood what needed to

You can say that again.
        
>Randy Menna

mike borza   <nusip at maccs.uucp or antel!mike at maccs.uucp>