Problem with cu script when uugetty is running

[Greg A. Woods]

In article <27281 at usc.edu> ami at kodkod.usc.edu (Ami Motro) writes:
>[re: problems after using uugetty in place of getty]
> It seems, though, that when I run cu (or uucico), the modem (a hayes
> compatible) does not respond to the AT command in the Dialers script with OK.

Do you know for sure that the "AT\r" is being sent?  Or is the cu/cico
hanging in the open(), and then timing out?

> It appears that the reason is the high DTR signal (from uugetty), because when
> I kill "cu", the DTR goes away for a while (until uugetty reasserts it), and in
> this period the Dialers script works fine.

This is extremely normal.  It means your port handles DTR correctly.

> Any clean solution to this problem?

Which OS are you using?  You need the most recent version of HDB-UUCP,
which comes with 3.2.x and perhaps 3.1.x (my memory is fuzzy here).  I
know 3.0 for most systems missed out on this feature.

This newer version has support for full modem control.  Previous
versions required the modem to tie DCD high, which in my books is a
*VERY* wrong way to do things.  Anyway, the test is to include lines
like these in the following files, and see if everything still works:

======== /usr/lib/uucp/Devices ========
Direct tty00M,M - 2400 directM
ACU tty00M,M - 2400 hayesne2400 \T
ACU tty00M,M - 1200 hayesne1200 \T
ACU tty00M,M - 300 hayesne \T

======== /usr/lib/uucp/Dialers ========
directM	""	"" \M\p
hayesne	=,-,	"" \M\dAT\r\c OK\r ATDT\T\r\d\d\c CONNECT \m\c
hayesne1200	=,-,	"" \M\dAT\r\c OK\r ATDT\T\r\d\c 1200 \m\c
hayesne2400	=,-,	"" \M\dAT\r\c OK\r ATDT\T\r\d\d\c 2400 \m\c

[ BTW, I realized just the other day how to keep phone numbers secure
from "cu -d", even with modems which echo.  If you turn echo checking
on in your dialer scripts (i.e. \E<dial-it>\e), the phone number
echoing will be eaten by cu, and only privileged users will be able to
see what is really being sent.  This is extremely trivial, and done by
default in many supplied systems, but I only recently realized the
implications.  I don't recall ever seeing this documented. ]
-- 
						Greg A. Woods

woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3-TCP	Toronto, Ontario CANADA