From: woods@robohack.UUCP (Greg A. Woods)
Subject: 3b2 EPORTS device driver bugs
Organization: Elegant Communications Inc.
Summary: CLOCAL vs. DCD and proper modem control functionality
Date: Mon, 4 Jan 93 06:25:31 GMT

I'm running (among other things) two modems on an EPORTS card plugged
into a 3b2/400 with UNIX SysV Rel. 3.1, and version 1.3 of the EPORTS
drivers.

Before I lost my AT&T 2224 modem, and other than the traditional
hardware flow control problems, I'd been quite happy with this setup.

However, as some of you may recall, I posted a note about a problem
which began to plague my Hayes 2400 and Telebit T-1000 some time ago.

The symptoms were a hung modem, and on the Hayes, the appearance of
RD, SD, TR, and MR being on continuously.  

Since I'm too poor to afford a fancy RS-232 protocol analyser, or even
a nice logic analyser, and my multi-channel scope is dead, I had no
idea what was actually happening to the ports.

The only solution to this lockup is to either cycle the power on the
affected modem, or to re-pump the firmware to the EPORTS card.

Eventually I discovered that running the modems with DCD in what I
call "interrupt" mode (i.e.  S131=3 on the T1000, or AT&C3 on other
conventional modems) effectively solved the problem.  (The Hayes
SmartModem 2400 couldn't do this, but since I only use it to dial out,
I can use AT&C0 for it.)

Recently I began experimenting with a new scheme for multi-class (link
layer protocol) dialer control for modern modems using entries like
these in the Devices file:

ACU 	tty32,M	- 19200	directM "" tb1init "" clocaloff "" tb1PEP "" tb1td \D
ACU	tty32,M	- 2400	directM "" tb1init "" clocaloff "" tb124 "" tb1td \D
ACUnC	tty32,M	- 2400	directM "" tb1init "" clocaloff "" tb124 "" tb1nC "" tb1td \D
ACU	tty32,M	- 1200	directM "" tb1init "" clocaloff "" tb112 "" tb1td \D
ACUkerm	tty32,M - Any	directM "" tb1init "" clocaloff "" tb1KERM "" tb1td \D

And like these in the Dialers file:

directM	""	"" \M\c
clocaloff ""	"" \m\c
tb1init	""	"" A\pA\pATZ OK-A\pA\pATZ-OK ATQ0E1 OK-ATQ0E1-OK
tb1td	=W-,	"" \EATDT\T\r\e\c CONNECT-\c-CONNECT-\c-CONNECT
tb1pd	=W-,	"" \EATDP\T\r\e\c CONNECT-\c-CONNECT-\c-CONNECT
tb112	""	"" ATS50=2 OK-ATS50=2-OK
tb124	""	"" ATS50=3 OK-ATS50=3-OK
tb1PEP	""	"" ATS50=255 OK-AS50=255-OK
tb1nMNP	""	"" ATS95=0 OK-ATS95=0-OK
tb1nC	""	"" ATS96=0 OK-ATS96=0-OK
tb1UUCP	""	"" ATS111=30 OK-ATS111=30-OK
tb1KERM	""	"" ATS111=13 OK-ATS111=13-OK

My original single-entry dialer had not used '\m', but since this is
the secret to having cu(1) say "disconnected" when the modem drops
DCD, I put it back in the dialer sequence.

Since that time, every (successful?) call out results in a subsequent
(but random?) series of locked up modems.  Eventually the frequency of
lock-ups is reduced.  (So I've again removed the clocaloff invocation,
and have gone back to ensuring I use '~.' to end calls).

I should also note that if the board is re-pumped, it seems no
subsequent lock-up's occur.

[Seems to be a plot against proper modem control and use of the modem
control features in HDB-UUCP (i.e. BNU)!]

So, does anyone have any clues?  Has anyone else experienced these
problems?  Does anyone have access to source for the EPORTS drivers
and firmware, and perhaps the ability to get this fixed and release
the fix?  While you're at it, could the hardware flow control be fixed
such that it can be permanently enabled at boot time for a given port?
-- 
						Greg A. Woods

woods@robohack.UUCP, woods@Elegant.COM  VE3TCP	UniForum Canada & ECI
+1 416 443-1734 [home] +1 416 362-XRSA [work]	Toronto, Ontario; CANADA
Newsgroups: comp.sys.att,comp.sys.3b1