Difference between revisions of "Handbook:Basic Server Configuration:Checking your Modem"

Revision as of 21:51, 17 December 2005

Once you have a modem to use with HylaFAX first make sure that the modem works for data use. One can not say this enough. If you can not use a communication program such as minicom, cu, tip, or kermit with your modem, do not try to configure it for use with HylaFAX. This means in particular that you should verify that you have a working cable between your host and modem and that this cable is suitable for use. That is, that the cable has the relevant signals for doing hardware flow control if that is necessary and that it passes the DCD and DTR signals appropriately.

If you're feeling ambitious, you can actually verify that the modem you are using is a fax modem. This can be done by communicating directly with the modem using a communication program such as cu; for example:

hyla% cu -l ttyf2
Connected
at+fclass=? 0,1,2
OK
~[hyla].
Disconnected

The at+fclass=? command asks the modem to report which classes it is capable of supporting. Class 0 is for data use. Class 1, Class 1.0, Class 2, and Class 2.0 are for facsimile use. Other classes may be reported, for example, for modems that provide digitized voice support. HylaFAX™ can be used with any modem that supports Class 1, Class 1.0, Class 2, or Class 2.0.

Selecting a Flow Control Scheme

Flow control refers to the mechanism used to control the transfer of data between the host and the modem (there may also be a flow control scheme used in modem-to-modem communication but the discussion here is specific to the scheme used between the host and a modem). The rules to use for selecting a host-modem flow control method for facsimile use are:

If you have a Class 1 modem, then you can use either hardware or software flow control, but beware of using hardware flow control as the Class 1 specification only requires vendors to support software flow control (and many of the Class 1 modems tried so far do not properly support hardware flow control).
If you have a Class 2 or Class 2.0 modem, then you can use either hardware or software flow control, but if you are going to communicate with the modem faster than 9600 baud then you should probably use hardware flow control.

Note! Beware that although a modem may properly implement hardware flow control when doing data communication, it may not support hardware flow control during facsimile communication. Consult the modem information for specifics on some modems.

When in doubt or having trouble, configure the modem to use software flow control for fax use.

Choosing a TTY device

There are two things to beware of in selecting a tty device file to use with your modem: flow control usage and port locking mechanisms.

On many systems different devices are used to select different flow control schemes and/or whether or not the system will monitor the DCD signal. For example, IRIX systems use ttym* and ttyf* device names to identify devices that monitor DCD but only the latter support RTS/CTS flow control. Similarly, the FAS driver for SCO uses a different names as does the standard HP-UX terminal driver.

On some systems inbound and outbound port use is interlocked by using a pair of devices, one for inbound use and another for outbound use. Typically this scheme works by stopping programs that use the inbound device until an inbound call is received (and DCD is raised by the modem). Outbound usage is also interlocked against applications waiting for the inbound device. HylaFAX provides no direct support for this because this scheme requires that a modem auto-answer incoming calls (something that is hard to make work with multi-mode--i.e. fax and data--modems). When faced with a system that uses this scheme most people elect to avoid the inbound device and run both incoming and outgoing traffic on the outbound device, using the built-in interlocking mechanism provided by HylaFAX. In this case the appropriate device to use is typically named /dev/cu*, but check local conventions.

On some systems, especially SVR4-based systems, device special files are located in subdirectories. Thus a typical device name might be /dev/term/10. HylaFAX server processes often reference a modem by a device identifier that is derived from the device filename by removing the leading /dev/ prefix and then converting any remaining ``/ characters to ``_ characters. Thus /dev/term/10 would have a device identifier of ``term_10. Usually this work is transparent and device filenames can be interchanged freely with device identifiers. However because of this interchangability it is not possible to use device files that have names that include ``_ in them, e.g. ``/dev/my_tty.

Using faxaddmodem to Configure Modems

Modems are configured for use with the faxaddmodem script. This is an interactive script that walks you through the configuration and installation of a new or existing modem. Even if you have a previous version of HylaFAX or FlexFAX installed it is a good idea to run faxaddmodem to update the configuration information for your modems after installing a new distribution.

faxaddmodem may be run directly from the command line or via the faxsetup script that is used to prepare a server machine for use with HylaFAX.

It would be nice to have a properly formatted walk-through with examples and explanation of each question here - DPN.

Starting Outbound Service

Outbound service is carried out by the HylaFAX scheduler process, the faxq(1M) program. There is one faxq process for all modems on a system. The faxq program learns about modems that can be used for outbound jobs by messages it receives on a FIFO special file located in the HylaFAX spooling area on the server machine. These messages come from two sources: from the faxmodem program that is used to manually enable a modem for use, or from faxgetty processes that are setup to run on each tty device where a fax modem resides.

Specifying modems with faxmodem is useful when HylaFAX is to be used in a send-only configuration. Doing this however limits the functionality of the scheduler because it will not know the true state of each modem; e.g. when a modem is in use by an outbound application such as uucp or tip. Instead faxq will assume that each modem is ready for use except when it is actively being used by HylaFAX to transmit a facsimile or alpha-numeric page.

A modem specified with faxmodem is identified by the tty device it is attached to. Thus, to notify the scheduler that two modems are available for use, the following might be used:

hyla# faxmodem tty01
hyla# faxmodem /dev/tty02

(note that devices may be specified with or without a leading /dev/ prefix.) Modem specified as above are assumed to have a default set of capabilities: whether or not they support polled retrieval of facsimile documents, what speeds they support for transmitting facsimile, whether or not they handle high resolution facsimile, etc. It is a good idea to specify the correct set of capabilities for a modem when using faxmodem, otherwise you may not get best use of a modem. Not identifying when a modem has limited capabilities can also cause HylaFAX to do extra work or cause errors that might be avoided.

Modem capabilities are specified through faxmodem with the syntax used by Class 2 and Class 2.0 modems. This makes it easy to setup a Class 2/2.0 modem: all you need to do is make a simple query to the modem to get the capabilities string to pass to faxmodem. For example, for a Class 2.0 modem the following commands would be used:

hyla% cu -l ttyf2
Connected
at+fclass=2.0
OK
at+fcc=?
(0,1),(0-5),(0-2),(0-2),0,0,0,(0-7)
OK

This sets the modem in Class 2.0 and then asks for the set of communication capabilities. The resulting string is then passed to faxmodem:

hyla# faxmodem -c '(0,1),(0-5),(0-2),(0-2),0,0,0,(0-7)' ttyf2

(note the quote marks around the string so that the shell does not interpret the parentheses).

For a Class 2 modem the commands are slightly different:

hyla% cu -l ttyf2
Connected
at+fclass=2
OK
at+fdcc=?
(0,1),(0-5),(0-2),(0-2),0,0,0,(0-7)
OK

For a Class 1 modem an entirely different procedure is needed because the modem only implements a small portion of the facsimile protocol. This means that the capabilities are mostly dependent on the HylaFAX software and not on the modem. The only information needed from the modem is which signalling rates are supported for transmitting fax data; this is obtained with:

hyla% cu -l ttyf2
Connected
at+fclass=1
OK
at+ftm=?
24,48,72,73,74,96,97,98
OK

and from there a capabilities string can be crafted by understanding that the above list indicates the modem can transmit at speeds from 2400 bps (24), 4800 bps (48), 7200 bps (72,73,74), and 9600 bps (96,97,98). (Multiple values for a particular speed indicate support for multiple modulation schemes; if any one value is reported then the corresponding speed should be specified in the capabilities string.) Thus the capabilities string is ``(0,1),(0-3),(0-2),(0-2),0,0,0,(0-7) (note the second segment is 0-3 instead of the 0-5 used above which indicated that the modem supported 12200 and 14400 bps signalling rates). Consult the faxmodem(1M) manual page for more information.

When faxq is used in conjunction with faxgetty no modems need to be specified using faxmodem. If modems are specified however; faxq will just treat the modems as ready for use until it receives more up to date information from the faxgetty processes.

@@ Line 31: / Line 31: @@
 On some systems, especially SVR4-based systems, device special files are located in subdirectories. Thus a typical device name might be '''/dev/term/10'''. HylaFAX server processes often reference a modem by a ''device identifier'' that is derived from the device filename by removing the leading '''/dev/''' prefix and then converting any remaining ``/'' characters to ``_'' characters. Thus '''/dev/term/10''' would have a device identifier of ``term_10''. Usually this work is transparent and device filenames can be interchanged freely with device identifiers. However because of this interchangability it is not possible to use device files that have names that include ``_'' in them, e.g. ``/dev/my_tty''.
-==Using faxsetup to Configure a Server Machine==
-Before any HylaFAX software can be used on a server machine the faxsetup script must be run. This interactive script verifies the installation of the HylaFAX™ software and also carries out a variety of one-time tasks that prepare the system for use. Running faxsetup is especially important when working from a binary distribution because it checks that parameters setup at the time the distribution was built are correct for the target machine where the software is to be run.
-faxsetup carries out a variety of tasks and then writes configuration information to two files in the HylaFAX™ spooling area. The file '''etc/setup.cache''' in the spooling area contains the parameter settings used by HylaFAX command scripts while the '''etc/setup.modem''' file contains settings and shell functions used by command scripts that communicate with modems.
-The work done by faxsetup includes the items listed below. Note that faxsetup always prompts for permission before doing anything that might affect normal system operation (e.g. adding a new user to the password file).
-* faxsetup verifies that the pathnames compiled into HylaFAX applications are correct and that the expected directory hierarchy used by client and server applications is present and setup correctly. If any of these checks fails then it is assumed that HylaFAX has not been installed or that there is a misconfiguration problem such as might occur when a binary distribution is loaded in an unexpected location.
-* faxsetup verifies that the TIFF software distribution is properly installed on the server machine. HylaFAX uses certain of the TIFF tools in normal server operation and, if the TIFF library has been built as a DSO, requires the TIFF library DSO for proper operation.
-* faxsetup verifies that the server machine is properly configured to support FIFO special files. Some operating systems are distributed without support for this feature and must be reconfigured before HylaFAX can be used.
-* faxsetup verifies that the configured PostScript RIP is present and that it has the necessary functionality to use it with HylaFAX. Ghostscript users must be sure to configure the ``tiffg3'' device driver when building Ghostscript for use with HylaFAX. IRIX users must be aware that the DPS-based RIP distributed for use with HylaFAX is a COFF executable that cannot be used under IRIX 6.2 or later.
-* faxsetup verifies that a ``fax'' user is registered in the password file or YP/NIS database. If one is not setup then one is created. The fax user is used in various places in HylaFAX and should be setup to have the same user ID as that of ``uucp'' so that UUCP lock files can be shared. (If you run IRIX the ``fax'' user will also be added to the '''passwd.sgi''' file so that it does not show up in the normal palette of users displayed during the login procedure.)
-* faxsetup verifies that suitable entries for the ``hylafax'' and ``snpp'' services exists in the '''/etc/services''' file or in the equivalent YP/NIS database. If no entries are present then they may optionally be setup (the software will still function properly without them).
-* faxsetup verifies that the hfaxd client-server protocol process is started up when the system is brought up multi-user or that hfaxd is started by the <tt>inetd(1M)</tt> program. hfaxd is the process that HylaFAX client applications communicate with to submit jobs, query server status, etc. It operates most efficiently when run in standalone but may also be invoked through inetd. Without hfaxd HylaFAX is basically useless.
-* faxsetup verifies that a ``FaxMaster'' entry is present in the aliases database. This alias is equivalent to the normal PostMaster alias that is used to deliver mail-related problems; HylaFAX directs notices about problems and received facsimile to this alias. The FaxMaster alias should list those system administrators that will handle HylaFAX-specific problems. If an alias is not present, then one is created.
-Following the above work faxsetup then prompts to create a configuration file for the HylaFAX scheduler process and for any modems on the system that are to be used by HylaFAX™. Finally the HylaFAX server processes are started up, or restarted if an existing installation is being updated or reconfigured, and any modem configuration work is performed. The following sections elaborate on this work and provide examples of how this work is done.
 ==Using faxaddmodem to Configure Modems==

Personal tools