Re: problem with inbound data calls

["David A. De Graaf" <degraaf@digitel.net>]

Jim Alumbaugh wrote:
> 
> 
> I'm using Hylafax v4.0pl1 on Linux Redhat distribution 4.0 with gcc 
> 2.7.2; USROBOTICS SPORTSTER 28800 V.34 modem.
> 
> Since rebuilding and reinstalling Hylafax, I haven't been able to get 
> FaxGetty to handle inbound data calls correctly.  
> 

I have nearly the same configuration, except a ZyXEL Omni 288S modem,
and had great difficulty getting the setup to work correctly.
So let me contribute 1) the quick answer, and 2) a lengthy
expostulation on modem ports.

1)  With HylaFAX, run faxgetty on /dev/cua1, not /dev/ttyS1 and make
sure all your other out-calling programs, cu, kermit, ppp, etc. use
that port too.  In /etc/inittab is the line:
    n:2345:respawn:/usr/local/sbin/faxgetty cua1

/var/spool/fax/etc/setup.cache should contain the line
    PATHGETTY='/sbin/getty'
It's put there when you run faxsetup, I think.

/var/spool/fax/etc/config.cua1 should contain the lines
    GettyArgs:              "-h %l F%s"
    ModemRate:              38400           # 38.4 works fine
    ModemFlowControl:       rtscts          # default

This will pick up the /etc/gettydefs entry:
    # 38400 fixed-baud modem entry
    F38400# B38400 CS8 # B38400 SANE -ISTRIP HUPCL #@S login: #F38400

Finally, make sure your modem is set *not* to autoanswer.


2)  There have been a number of conversations in this list indicating
confusion about modem ports.  At the risk of being redundant, boring,
or wrong, let me offer my understanding of the difference between
normal UNIX and HylaFAX usage of the modem port.

On a modem port two separate things have to happen.  First, a process camps
on the line waiting for a call to come in.  Second, whenever users choose,
an out-calling process grabs the line and sends modem commands to make
a call.  The second must not conflict with the first, and only one
such out-caller may use the port at a time.  Lock files are used to
avoid conflicts.

There are two different design approaches to the first problem.
Let me call them the passive and active methods.  UNIX systems
generally use the passive method;  HylaFAX (and DOS programs) uses the
active method.

In the passive (UNIX) method, the process looking for an incoming call
(getty, uugetty, ttymon, or such) tries to issue a login: prompt, but
the write system call blocks until the CD (carrier detect) goes high. 
That is, it lets the modem do all the work of answering the phone.
Only after the modems have negotiated a connection does the write
unblock so the login process can continue.  This means that the modem
must be prearranged to autoanswer (S0=1), it must not emit spurious
messages that might be interpreted as a loginid by the listening
process (ATE0Q1), and it should send characters to the computer at a
predetermined baud rate regardless of the modem's negotiated link speed
(ATS18=4, to set my modem to 38400; different for other modems). 
The modem must use this locked baud rate even though no characters have
been received from the computer.  (Some modems cannot do this; they
only remember the last speed that the computer used.)  All this is
ensured by setting the right active parameters into the modem,
including AT&D3, and then copying them to the stored profile (AT&W).
The &D3 will cause these "correct" parameters to be restored every time
the modem hangs up.  Out-calling programs must use scripts that set
ATE1Q0; else the modem will not respond and appear dead.

Some UNIX systems (Linux, Solaris) provide separate devices for
incoming and outgoing calls on the same physical serial port
(/dev/ttyS1 vs. /dev/cua1 in Linux).  "Modem control", ie, the ability
to block until CD rises, is implemented on one and not the other. 
In UNIX SysV a single device file handles both incoming and outgoing
calls.


In contrast to all this, HylaFAX uses the active method and controls
the modem in a much more forceful and interactive manner. 
When faxgetty starts, it sends a long string of commands to establish
the DTR baud rate and set up the modem exactly the way it wants it, and
then reads whatever messages the modem emits.  It is waiting for "RING"
to show up.  When it does, minutes or days later, faxgetty sends ATA to
make the modem go "off-hook".  Other interactions follow, during which
faxgetty decides if the call is fax, data, or something else.  If it's
a data call, faxgetty self-destructs by exec'ing the program in
$PATHGETTY with the options in $GettyArgs, so getty (or ttymon, or ...)
has the opportunity to establish a login.  When the call eventually
terminates, the /etc/inittab entry causes a new faxgetty to be
started.

The major implications of this are  
1)  The modem must not be set to autoanswer, because faxgetty is
expecting to issue ATA after a suitable number of RING's.
2)  faxgetty behaves like an out-calling program.  It must use the
device that out-calling programs use.
3)  To ensure that the locking mechanism works properly, all out-calling 
programs (faxgetty, cu, uucico, kermit, ppp, etc.) should use the same
device file, because lock files are created for specific devices.

-- 
	Dave De Graaf,  Internet: degraaf@digitel.net
	DATIX, Inc.	voice: (803) 785-3136	fax: (803) 785-3156