Xref: utzoo comp.sys.att:8016 comp.unix.i386:1161
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bfmny0!tneff
From: tneff@bfmny0.UU.NET (Tom Neff)
Newsgroups: comp.sys.att,comp.unix.i386
Subject: IPC802/uugetty problem on 6386 V3.2
Summary: dialins not recognized after 1st onhook
Message-ID: <14900@bfmny0.UU.NET>
Date: 11 Nov 89 22:53:58 GMT
Reply-To: tneff@bfmny0.UU.NET (Tom Neff)
Followup-To: comp.sys.att
Distribution: na
Lines: 32
Expires:
Sender:
Followup-To:

I have a problem that I wonder if anyone else has encountered.  On my
AT&T 6386E WGS under UNIX V/386 3.2.1, I've got an IPC802 intelligent
ports card with the 3.0 drivers installed.  Courier 2400 modem on one
port, ttyh01.  Uugetty owns the port so I can mix UUCICO dialouts with
dialup logins.  Almost everything works great, except that if I dial up
and log in and eventually hang up, then the NEXT time I dial in, the
modem will CONNECT but uugetty won't issue a login: prompt.  This
remains true no matter how many additional times I log in, or what I do
on the line after CONNECT -- hit returns, breaks, keys etc.  The only
thing that repairs it is when UUCICO runs hourly and does its thing!
Afterwards, I can usually log in again -- once.

Naturally I figure something isn't being left in the proper state on
the line, but I dunno what.  Here is the /etc/gettydefs entry for 2400
(reformatted onto 4 lines so nobody's news blows up):

| 2400# B2400 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY PARENB ISTRIP
| ECHO ECHOE ECHOK ICANON ISIG CS7 CREAD # B2400 OPOST ONLCR TAB3
| BRKINT IGNPAR IXON IXANY PARENB ISTRIP ECHO ECHOE ECHOK ICANON ISIG
| CS7 CREAD #login:  #1200

And here's the /usr/lib/uucp/Dialers entry (reformatted) for my modem:

| RixonUsrCourier2400	=,-,	"" \M\dATQ0V1\r\c OK\r AT&F\r\c OK\r
| ATM0\r\c OK\r AT&D2\r\c OK\r AT&C1\r\c OK\r ATS0=1\r\c OK\r
| \EATDT\T\r\c CONNECT \r\m\c

If anyone has any bright ideas, please let me know.  If you mail I'll
summarize.  If you give me your cabin by the lake I'll summerize. :-)
-- 
Knowing *when* to optimize is just   >>>/     Tom Neff
  as important as knowing *how*.       /<<<   tneff@bfmny0.UU.NET