grr@cbmvax.UUCP (George Robbins) (02/20/88)
XYZXYZ Warning: this may be Ultrix 1.2 specific XYZXYZ
A couple of days ago I posted some fairly detailed documentation about using
the Ultrix acucap routines, with emphasis on DMF-32 interfaces. I haven't
seen the posting come back yet, but have spend some time actually trying
out the various options. It's been kind of "interesting" and I now have a
better idea about what kind of things "go wrong" when you try to make some
changes to the acucap entries or try to do your own.
Having identifed all these problem, it is only fair to admit that I *have*
gotten the acucap/generic dialer facility to work fairly reliably, however
I am letting the pain recede a bit before I presume to post expamples of
working acucap entries.
My general feeling is that while the acucap facility seems to give a
lot of options for auto-dialer control, it is actually quite limited in
the extent to which you can explictly control the dialer. All you can
really do is parameterize a fixed sequence of operations. The dialer
code contained in the current 4.3 BSD UUCP includes provisions for
putting modem initialiaztion chat scripts in the L-devices entry for
each line, in conjunction with a larger assortement of built-in dialers.
This actually gives more control over the actual dialing process, since
the chat scripts provide the same interpretation of the send strings
as in the L.sys file and also rudimentary test/retry/abort options.
---------------
First, in the last document, all references to :lt: should really read :ls:,
which stands for "local sleep" - somehow I was thinking "local time".
Some new observations:
1) For the delays that can be specified in the acucap file, the default
or "error" value is -1, therefore if you specify an option that implicitly
involves a delay, you must specify some value for the delay.
2) Normally, specification of a zero delay means "no delay", however when
the "local sleep" (:ls:) option is used, a zero delay actually results
in an indefinite delay.
3) These errors (1,2) are indicated when the debug display from the output()
routine shows the string to be output, then stops after displaying
the hex value of the first character. This symptom may also indicate
that the acucap entry has some error and has not been completely
processed, for instance, a continuation character may have been omitted.
4) There is a program bug in the timeout/delay for the "dial response"
(:dr:) option such that if you specify the :ls: option in conjunction
with the :dr: option, the dialer will wait indefinitly after displaying
the "dials = 5551212" debug message. If you need the check for the
dial response string, you must use the normal one second granularity
timer.
5) If you specify the "wait for carrier" :cr: option and you are using
an interface like the DMF-32 and the modem is configured not to assert
carrier in command mode and you specify a "disconnect string" (:ds:)
the dialer may block indefinitly trying output the disconnect string.
There may be other options indicated here, but the problem is simply
the the dialer should be doing a ioctl(TIOCNCAR) to disable any blocking
before attempting to send the disconnect string. The symptoms of this
problem are that after the dialer displays the "gendisconnect" message,
it stops after displaying the hex value of the first character of the
disconnect string much as in (3) above. An alternate indication is
when the dialer logs error messages to the L.sys file, but uucico never
terminates.
6) The above problem (5) seems to occur when using the sample acucap
entries on a DMF-32 interface unless the modems are set-up to always
provide carrier detect/data set ready in command mode. Unfortunatly
with this setting, the modems will not "share", since the presence
of DSR prevents getty from relinquishing the modems. Attempting to
disable CD/DSR in command mode will result in uucico hanging while
trying to send the disconnect string. A solution is simply to delete
the disconnect string and rely on the :hu: option to terminate any
connections.
7) Note that the "hang up on close" (:hu:) option doesn't really affect
dialer operation, since this this mode is always set up by the general
setup code. Still, unless there is some good reason not to, you should
probably always specify :hu: and :re: to minimize the possibility of
leaving your modems wedged off-hook.
8) Note that the "online string" (:os:) must have been received within
one second of carrier detect being asserted or the dialer will time-out.
Users of modems on DMF-32 or other interfaces that have must have carrier
present to receive any responses from the modem, must instead use the
"dial response" (:dr:) and "dial acknowledge" (:da:) options if they
wish to check for "CONNECT" or "ON-LINE" type strings.
9) Note that the way the "dial acknowlege" (:da:) delay is implemented,
the dialer waits for the specified period after dialing, then checks
if the "dial response" (:dr:) strings has been recieved. If the
dial response option is being used to check for other than an immediate
"number accepted/dialing begins" message, the delay value must be a
compromise between the maximum time needed to establish the connection
and the time the remote system will wait for a response to it's login:
prompt before dropping the line.
10) Note that unlike the "built-in" dialers which use the first device
name specified in the L-devices entry for a line, the generic dialer
uses the second device. Always specifying the same name for both
devices should cause no problems?
----------------------
Some documentation on the debugging output from the low level routines
that actually handle the acu output and input/match actions.
output() is used to output a text string with a specified delay between each
character. There is no "interpretation" of the text string, this is handled
in the acucap aka termcap reading routines. Depending on the setting of the
:ls: boolean option, the delay is in seconds, using the sleep(3) routine, or
in microseconds using the setitimer(2) facility. Note that for sleep(), a
zero argument means no delay, while for setitimer() zero seems to mean wait
forever.
output(string,delay)
====================
ddebug "output: <string>"
for each character
ddebug " %x"
input() is used to compare received input against a text string. It really
expects the input to already be present and times out after only one second.
input(work,expect)
==================
do
select() - test for chars/timout
if timeout
ddebug "input: failed <characters>"
return bad
read(characters)
until match(characters,expect)
ddebug "input: <characters>"
return good