serial port grief with A/UX 2.0

[Alexis Rosen]

(I don't think this went out yet, but if it did, sorry for the re-post...)

For the past few days I have been trying to attach a stack of 2400bps modems
to my A/UX box with little success. While the problems may be A/UX specific,
the conditions may be analogous to other (possibly similarly broken) unixes,
and thus the crosspost.

The problems are that:
1) modems answer the phone, but the getty doesn't wake up and send the prompt.
2) modems answer the phone, and the getty wakes up and sends the prompt, but
   nothing typed to the login prompt registers. The getty eventually hangs up.
3) uucico, cu, kermit, etc., can't get the line, even though the device isn't
   in use and there's no lock file.

The details:
The mac has two 4-port Taniwha Systems CommCards. But these aren't at fault,
since the problems also appear when I use the two ports built into the Mac.
The modems are all various 2400bps modems (Prometheus, Supra, and Maxxum) but
their command sets are identical, including the various S-registers.

The serial cables are part of the problem. I'd think that DCD wasn't being
connected properly, but if so, why did the same modem/cable pair that worked
yesterday fail today? and why did the pair that didn't work yesterday work
today? Unfortunately, there's no way this can all be the fault of some cables,
although they may be contributing (I've got some new ones coming).

One of the port/cable/modems works fine now (although it's not starting out
with the right line speed and parity, a break fixes that). stty -a tells me
that the settings are identical on all three ports. On the other two ports,
when you dial in the modem answers but you get nothing from getty.

However, when it comes to dialing out, it's a different story. The line which
I can dial in to (ttyb0) is inaccessable. Likewise for one of the dead lines
(ttyb1). But the other line (ttyb2) works fine. cu and uucico have no problem
using it.

stty sees no difference between these three lines, but I do. Look:
> ps -ef |grep ttyb
    root  2165     1  0 02:51:14 ?        0:00 /etc/getty -t90 ttyb0 mo_2400
    root   128     1  0 21:08:39 ?        0:00 /etc/getty -t90 ttyb1 mo_2400
    root  2202     1  0 03:07:06 b2       0:00 /etc/getty -t90 ttyb2 mo_2400
    root  2206  2177  2 03:08:03 a0       0:00 grep ttyb

(I'm a little hazy on the unix internals part of this, but...) The way I read
this is, that the b2 getty has acquired /dev/ttyb2, but the other two gettys
do not yet own their terminals. In fact, the b2 getty is doing the wrong thing
(probably because of an iffy cable?)- this is a bidirectional getty, and it
is not supposed to grab a line until it sees activity. In Unixspeak (let's see
if I can get this right) the open on ttyb2 isn't supposed to complete until
DCD goes high, which only happens when the modem answers a phone call.

So what this seems to imply is that cu and uucico need DCD high in order to
grab the line. This is not possible, since I know for a fact that two days
ago I was able to cu to all three of them (but, at that point, I couldn't
dial in to any of them).

In case it might help, here's what uucico had to say about things:
About to call ulockf(LCK..ttyb0)
 enter us_sst, status is : 05
Lockfile /usr/spool/uucp/LCK.LSTAT is null
s.sysname :    cmcl2
 enter ub_sst, status is : 5
Rmtname: cmcl2
Lockfile /usr/spool/uucp/LCK.LSUB is null
exit code 0

This doesn't mean much to me. cu had this to say: "Connect failed: no answer".

One more wierdness- when I was trying to get things working, I reached a
point where two of the modems would answer, and getty would recognize this,
since it would print the initial login prompt. But anything typed to login
would be ignored. It was as if the mac could send but not receive characters
(but that's impossible, since at that point cu worked).

All in all, this is most frustrating. The fact that rebooting the system had
some effect (changed which lines worked and which didn't) makes things all the
more confusing. At least the telebit's stable...

At this point I'm grasping at straws. If you have any idea what might be
wrong, even if you've never touched a Mac, I'd love to hear from you.

Followups to comp.unix.aux. Mail to me, please, too- until I get this fixed,
my time for newsreading is somewhat limited...

Thanks in advance,
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix
{cmcl2,apple}!panix!alexis