efax.1

使用efax的fax工具程序

rings.  The example below will make the modem answer incoming
calls in fax mode on the fourth ring and save the received faxes
using files names corresponding to the reception date and time.

.RS
.nf
.ft CW
efax -d /dev/ttyb -or -i"+FCLASS=2;+FCR=1" \\
   -iS0=4 -w -r "" 2>&1 >> fax.in.log
.ft P
.fi
.RE

.B Sharing the modem with outgoing calls

The modem device can be shared by programs that use the UUCP
device locking protocol (kermit, uucico, efax, cu, etc.).

efax will lock the modem device before opening it if one or more
UUCP lock file names are given with \fB-x\fP options.  The lock
file names are typically \fR/usr/spool/uucp/LCK..\fP\fIdev\fP
where \fIdev\fP is the name of the device file in the /dev
directory that is to be locked.

If the \fB-s\fP (share) option is used, the lock file is removed
while waiting for incoming calls so other programs can use the
same device.

If efax detects another program using the modem while it is
waiting to receive a fax, efax exits with a termination code of
1.  A subsequent efax process using this device will wait until
the other program is finished before re-initializing the modem
and starting to wait for incoming calls again.

Programs that try to lock the modem device by using device
locking facilities other than UUCP lock files not be able to use
this arbitration mechanism because the device will still be open
to the efax process.  In this case you will need to kill the efax
process (e.g. "fax stop") before starting the other program.

.B Accepting both fax and data calls

Many modems have an adaptive data/fax answer mode that can be
enabled using the \fB-i+FAE=1\fP (for Class 1) or \fB-i+FAA=1\fP
(for Class 2) initialization string.  The type of call (data or
fax) can then be deduced from the modem's responses.

Some modems have limited adaptive answer features (e.g. only
working properly at certain baud rates or only in Class 2) or
none at all.  In this case use the initialization string
\fB-i+FCLASS=0\fP to answer in data mode first and the \fB-oa\fP
option to then hang up and try again in fax mode if the first
answer attempt was not successful.  This method only works if
your telephone system waits a few seconds after you hang up
before disconnecting incoming calls.

If the \fB-g\fP option is used, the option's argument will be run
as a shell command when an incoming data call is detected.
Typically this command will exec \fBgetty\fP(8).  This program
should expect to find the modem already off-hook and a lock file
present so it should not try to hang up the line or create a lock
file.  Note that the modem should be set up to report the DCE-DTE
(modem-computer, e.g. CONNECT 38400) speed, not the DCE-DCE
(modem-modem, e.g. CONNECT 14400) speed.  For many modems the
initialization option -iW0 will set this.

The following command will make efax answer incoming calls on
\fB/dev/cua1\fP on the second ring.  This device will be locked
using two different lock files but these lock files will be
removed while waiting for incoming calls (\fB-s\fP).  If a data
call is detected, the \fBgetty\fP program will be run to
initialize the terminal driver and start a \fBlogin\fP(1)
process.  Received fax files will be stored using names like
\fBDec02-12.32.33.001\fP, in the \fB/usr/spool/fax/incoming\fP
directory and the log file will be appended to
\fB/usr/spool/fax/faxlog.cua1\fP.

.RS
.nf
.ft CW
efax -d /dev/cua1 -or \\
   -i '+FCLASS=2;+FCR=1;+FAA=1' \\
   -x /usr/spool/uucp/LCK..cua1 \\
   -x /usr/spool/uucp/LCK..ttyS1 \\
   -g "exec /sbin/getty -h /dev/cua1 %d" \\
   -iS0=2 -w -s \\
   -r "/usr/spool/fax/incoming/%b%d-%H.%I.%S" \\
   >> /usr/spool/fax/faxlog.cua1 2>&1
.ft P
.fi
.RE

Note that adaptive answer of either type will not work for all
callers.  For some data calls the duration of the initial
data-mode answer may be too short for the initial handshaking to
complete.  In other cases this duration may be so long that
incoming fax calls will time out before efax switches to fax
mode.  In addition, some calling fax modems mistake data-mode
answering tones for a fax answer (CED) tone and initiate fax
negotiation too soon.  If you use software adaptive answer you
can reduce the value of the initial data-mode answer (set by
TO_DATAF in efax.c) to get more reliable fax handshaking or
increase it for more reliable data handshaking.  However, if you
need to provide reliable fax and data service to all callers you
should use separate phone numbers for the two types of calls.

.SH USING INIT TO RUN EFAX

efax can answer all incoming calls if you place an entry for efax
in \fB/etc/inittab\fP (for SysV-like systems) or
\fB/etc/ttytab\fP (for BSD-like systems). The \fBinit\fP(8)
process will run a new copy of efax when the system boots up and
whenever the previous process terminates.  The inittab or ttytab
entry should invoke efax by running the \fBfax\fP script with an
\fBanswer\fP argument.

For example, placing the following line in \fB/etc/inittab\fP
(and running "kill -1 1") will make init run the \fBfax\fP script
with argument \fBanswer\fP every time previous process terminates
(and \fBinit\fP is in runlevel 4 or 5).

.RS
.nf
.ft CW
s1:45:respawn:/bin/sh /usr/bin/fax SPKR=-iM0 answer
.ft P
.fi
.RE

For BSD-like systems, a line such as the following in
\fB/etc/ttytab\fP will have the same effect:

.RS
.nf
.ft CW
ttya "/usr/local/bin/fax answer" unknown off
.ft P
.fi
.RE

In these cases the fax script should be protected against
tampering since init will execute it as a privileged (root)
process.  If you will also be allowing data calls via getty and
login you should ensure that your system is reasonably secure
(e.g. that all user id's have secure passwords).

.SH RESOLVING PROBLEMS

Double check the configuration setup in the fax script.

Run the "fax test" script to check the modem's responses to
various commands.  The results will be displayed at the end of
the test.  Some ERROR responses from the modem should be expected
since most modems don't implement all the possible commands.

If efax hangs when trying to open the modem device (typically
ttyX), the device is either already in use by another process
(e.g. getty) or it requires the carrier detect line to be true
before it can be opened.  Many systems define an alternate device
name for the same physical device (typically cuaX) that can be
opened even if carrier is not present or other programs are
already using it.

If modem responses are being lost or generated at random, another
processes (e.g. getty) may be trying to use the same device at
the same time.  Using lock files (-x options) can sometimes
resolve this problem.

Check the response to the "AT+FCLASS=?" command to make sure your
modem supports the Class (1 or 2) that you have selected.  If you
have a Class 1 modem, check the response to the "AT+FRM=?"
command to verify the speeds supported (e.g. a response of
"24,48" would mean only 2400 and 4800 bps are supported).  For
Class 2 modems check the response to the "AT+FDCC=?" command to
make sure the modem supports the capabilities you have selected
(see CAPABILITIES above).

Attempt to send a fax. Check that the modem starts making CNG
tones (a 0.5 second tone every 3 seconds) as soon as it's
finished dialing.  This shows the modem is in fax mode.  You may
need to change the SPKR string in the fax script to -iM2L3 to
monitor the phone line.

Listen to the answering fax machine and check that it sends a 3
second beep (CED) followed by a "warbling" sound (DIS frames)
every 3 seconds.  If you hear a continuous signal instead (tones
or noise), then you've connected to a data modem instead.

Your modem should now send back another warble (DCS frame)
followed by 1.5 seconds of noise (training check data).  If
everything is OK, the receiving end will send another warble (CFR
frame) and your modem will start to send data.  Check the modem's
LEDs.  If flow control is working properly, the modem's send data
(SD) LED will turn off periodically while the fax data is sent.

When the transmission completes, check the message showing the
line count and the average bit rate.

Low line counts (under 1000 for a letter size image) or the
warning "fax output buffer overflow" indicate that the image
format is probably incorrect. Possibly the bit order is reversed.

If the average bit rate is much higher than the negotiated bit
rate (e.g. 14000 bps for a 9600bps connection) then flow control
was not active.  This usually results in a garbled transmission
and the receiving machine may reject the page, abort the call,
print a distorted or blank image and/or hang up.

Most modems enable XON/XOFF flow control when fax mode is
enabled.  Check the output of the fax test command for the flow
control settings in fax mode (typically &K4 or \\Q1).  If they
are incorrect you can use additional -i commands to enable flow
control after the +FCLASS= command.

An <XOFF> message appearing during the transmission means that
the operating system was ignoring the modem's XON/XOFF
characters.  This could be caused by bugs in the serial driver
(some Linux 1.1 kernels before 1.1.42).  In this case use the
stty command to check the definitions of the start and stop
control characters and to check if xon/xoff flow control is
enabled.  You can use stty to set up the port manually (stty stop
^S start ^Q ixon </dev/XXX) before starting efax if necessary.

Check that the remote machine confirms reception with a +FTPS:1
response (Class 2) or an MCF frame (Class 1).

For Class 2 modems, the error message "abnormal call termination
(code \fInn\fP)" indicates that the modem detected an error and
hung up.  The modem's manual may give an explanation for the
error number \fInn\fP.

Many companies advertise services that will fax back information
on their products.  These can be useful for testing fax
reception.

If efax should display the message "can't happen (<details>)"
please send a bug report to the author.

Finally, don't play "option bingo," if you can't resolve the
problem save the output of the \fBfax test\fP command to a file
(e.g. \fBfax test >test.out\fP) and send it along with a verbose
(\fBVERB="-v chewmainr"\fP) log of the failed session to the
address below.  You may also want to use the mailing list
described below.

.SH MAILING LIST

A mailing list has been set up to support users of efax and
related software.  To subscribe, send e-mail to
[e-mail] with the word "subscribe" in the
subject field.  After subscribing you can post to the mailing
list by sending your post to [e-mail].

.SH RELATED SOFTWARE

For Linux Systems

An independent package, Qfax, uses efax to provide fax services
for multiuser Linux systems through a mail-to-fax gateway.  It is
available by anonymous ftp from sunsite.unc.edu as
/pub/Linux/apps/comm/fax/qfax1.0.tar.gz.  Another program, g3vga,
can be used to provide fax preview with VGA displays. Also
available from sunsite.unc.edu.

For Amiga Systems

A port of efax for the Amiga is available as a component of a
shareware voice mail package, AVM, distributed by Al Villarica
([e-mail]).

.SH AUTHOR

Efax was written by Ed Casas.  Please send comments or bug
reports to [e-mail].  Please mention the operating system, the
type of the modem used and include a copy of any relevant session
logs.

.SH ACKNOWLEDGEMENTS

Many people have helped with the development of efax by providing
encouragement, suggestions, bug reports and fixes, by doing
pre-release testing and by developing related software.

A very incomplete list includes: 
John Conover, 
Mitchum DSouza, 
Bradley Dale, 
Debbe Gervin, 
Jamie Honan, 
Michael Huehne,
Lester Ingber, 
Sarantos Kapidakis,
Al Knudson, 
Ken Land,
Ulrich Lauther, 
Robert J. LeBlanc,
Norm Matloff, 
Mark Montague, 
Jose' M. Piquer, 
Markus Regnet, 
Adam J. Richter, 
Lal Sanjay,
Bogdan Urma,
Derek Lee,
and 
Al Villarica.

.SH COPYRIGHT

efax is copyright 1993, 1994, 1995 Ed Casas.  It may be used,
copied and modified under the terms of the GNU Public License.

.SH DISCLAIMER

Although \fBefax\fP has been tested it may have errors that will
prevent it from working correctly on your system.  Some of these
errors may cause serious problems including loss of data and
interruptions to telephone service.

.SH REFERENCES

Dennis Bodson et. al., "FAX: Digital Facsimile Technology and
Applications", Second Edition. Artech House, Boston. 1992.

CCITT Recommendation T.4, "Standardization of Group 3 Facsimile
Apparatus for Document Transmission". 1988.

CCITT Recommendation T.30, "Procedures for Document Facsimile
Transmission in the General Switched Telephone Network". 1988

The above CCITT (now ITU-T) standards can be downloaded from
gopher://info.itu.ch.

Documentation on Class 1 and Class 2 fax commands as implemented
by Rockwell are available from
http://www.tokyo.rockwell.com/ref/reference.html.

The pbm utilities can be obtained by ftp from wuarchive.wustl.edu
in /graphics/graphics/packages/NetPBM/netpbm-1mar1994.tar.gz.

Ghostscript can be obtained from any GNU archive site.

.SH SEE ALSO

.BR fax(1),
.BR efix(1),
.BR pbm(5),
.BR g3topbm(1),
.BR ghostscript(1),
.BR init(8), 
.BR inittab(5), 
.BR ttytab(5), 
.BR printf(3),
.BR strftime(3).

.SH  BUGS

Class 1 operation may fail if the program can't respond within 55
milliseconds.

May fail if multitasking delays cause the received data to
overflow the computer's serial device buffer or if an under-run
of transmit data exceeds 5 seconds.

Does not handle documents with pages of mixed formats or 2-D
coding.  Does not do ECM, BFT, or polling and ignores procedure
interrupts.

Can't read or write TIFF-F files.