Server Setup and Basic Configuration

A system acting as a HylaFAX™ server usually runs at least two server processes: the HylaFAX™ scheduler process faxq and the client-server protocol process hfaxd. Server systems may also use the HylaFAX™ front-door process faxgetty to monitor each modem on the system and possibly receive incoming facsimile calls. A send-only system would run faxq and hfaxd but (probably) not faxgetty. A system that was not going to use the transmit capabilities would not run faxq.

In addition to the server processes that operate all the time HylaFAX™ comes with two programs that are intended to be run periodically. The faxqclean program is responsible for purging unwanted files from the spooling area on a server and the faxcron script monitors the spooling area and performs routine maintenance tasks such as truncating log files. These programs are usually invoked by the system cron program.

The remainder of this chapter discusses the basic steps required to setup a HylaFAX™ server machine:

1. Install the HylaFAX™ software.
2. Select a facsimile modem for use.
3. Check your modem is functional.
4. Select a flow control scheme to use for facscimile communication.
5. Select a TTY device to use.
6. Use faxsetup to configure a server machine.
7. Use faxaddmodem to configure modems.
8. Startup outbound service.
9. Setup the modem for inbound use [optional].
10. Setup client access.
11. Setup periodic maintenance work.

Installing HylaFAX™

hyla# make install # NB: must be done by the super-user

When working from a binary distribution the technique required to install the software programs varies based on the format used to distribute the materials. Each binary distributions of HylaFAX™ should include detailed installation instructions that reflect the exact contents of the distribution and any distribution-specific requirements.

Checking Your Modem

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

Selecting a Flow Control Scheme

• 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.

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.

If a prototype configuration file for your modem is included in the HylaFAX™ distribution then the appropriate default flow control scheme should be defined for the modem.

Note that some operating systems do not support RTS/CTS flow control unless carrier is present. In particular, some versions of SunOS and Solaris requires patches to correct this mis-behaviour; consult the sections below for system-specific guidance.

Versions of IRIX prior to 6.2 have a bug in the device driver for the on-board serial ports on IP20 and IP22 systems that causes RTS/CTS flow control to be turned off by HylaFAX™. Patch 475 (``RTS/CTS flow control busted when CLOCAL is set'') and its successors correct this problem and must be installed to use HylaFAX™ with hardware flow control. For complete details refer to the section below on IRIX-specific guidance.

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

Choosing a TTY Device

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 faxsetup to Configure a Server Machine

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 setup.cache and setup.modem files must be present for HylaFAX™ to function properly. If these files do not exist then HylaFAX™ server applications will terminate with an error message.

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 inetd(1M) 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.

Using faxaddmodem to Configure Modems

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™.

The remainder of this section shows a sample configuration session and describes the work done. The session is shown on the left hand side in a fixed width font with user-supplied input in a bold font. Comments are shown to the right in a normal or italic font, separated by horizontal rules. Blank space is present in the session output where it is needed to fit comments on the page; in normal operation the output from faxaddmodem does not include this white space. faxaddmodem displays the current/default setting for a configuration parameter enclosed in ``[]''; the current value is accepted by typing a carriage-return.

This session was collected on a Silicon Graphics Indy machine running IRIX 5.3 and communicating with a USR Courier v.Everything modem.

hyla# faxaddmodem ttyf2 Ok, time to setup a configuration file for the modem. The manual page hylafax-config(4F) may be useful during this process. Also be aware that at any time you can safely interrupt this procedure.	If your modem is configured to communicate with the host at a fixed speed, then use the -s option to lock the host-modem baud rate. Note also that faxaddmodem must be run as root.
Collect server-specific configuration parameters. Per-modem configuration files contain parameters that pertain to the operation of the modem and parameters that control the function of the HylaFAX™ server software that controls the modem. The former parameters are termed modem-specific while the latter are referred to as server-specific. faxaddmodem collects server-specific parameters first and then modem-related parameters are setup based on the type of modem.
Reading scheduler config file /var/spool/hylafax/etc/config.	The configuration file for the HylaFAX™ scheduler is automatically read to get default settings for parameters such as the area code.
No existing configuration, let's do this from scratch.	If a configuration file already exists for a modem, the server-specific parameters will be carried over to the new configuration, but the modem-specific parameters will not.
Country code [1]? Area code [510]?	The area code may be set to a null string or omitted in locations where one does not exist.
Phone number of fax modem [+1.999.555.1212]? +1 510 526-8788	This is the phone number associated with the modem. By default this number is passed as an identity to peer fax machines (see below) and it may also appear on tag lines created by the fax server.
Phone numbers should be supplied with a complete international dialing specification: ``+<country code> <local part>'' (the <local part> includes an area code where such a notion exists.)
Local identification string (for TSI/CIG) ["NothingSetup"]? ""	The local identification string is passed to peer fax machines during communication. If it is not specified, or set to a null string, then the canonical phone number of the fax modem is used instead.
Beware that the facsimile communication protocol restricts the local identification string to numbers, blank, and the ``+'' symbol. In practice however, most facsimile machines will accept any ASCII string.
Long distance dialing prefix [1]? International dialing prefix [011]? Dial string rules file (relative to /var/spool/hylafax) [etc/dialrules.sf-ba]?	The dial string rules file holds rules used to convert user-supplied dialing strings (i.e. phone numbers) to a canonical format and to prepare strings for delivery to a modem. The default rules do very little. Specific dialing rules may be useful for your site or locale based on how your modems are connected to the PTT. Consult the section in the Advanced Server Configuration chapter for more information.
Tracing during normal server operation [1]? Tracing during send and receive sessions [11]?	These parameters control the logging done by server processes.
It is important that tracing during send and receive sessions include sufficient information to diagnose problems. For Class 1 modems this parameter is usually set to 0x4f so that HDLC frames are included in the logs. For Class 2 and Class 2.0 modems the default setting of 11 is typically ok. Consult the descriptions of ServerTracing and SessionTracing in the hylafax-config(4F) manual page.
Protection mode for received facsimile [0600]?	The default parameter selected here makes all received facsimile accessible only to the fax user. It may be desirable to set this parameter to 0644 so that anyone can look at received facsimile.
Protection mode for session logs [0600]? Protection mode for ttym2 [0600]?	Note that if sensitive information such as credit card access codes are supplied by users that they will appear in the session logs kept on the server machine. For this reason the default protection mode for session logs protects them from public access.
Rings to wait before answering [1]?	This parameter is used during inbound call handling. It specifies the number of rings to wait before answering the phone. See the section on inbound call handling for a discussion of the different schemes that are supported for handling calls.
Modem speaker volume [off]? Command line arguments to getty program ["-h %l dx_%s"]?	This parameter is also related to inbound call handling. It controls whether or not to enable support for inbound data calls and should not be set without first understanding how to setup your system for incoming data usage.
Pathname of TSI access control list file (relative to /var/spool/hylafax) [""]?	The TSI access control list file can be used to restrict inbound facsimile access. The default parameter causes all inbound calls to be accepted. This parameter is discussed more below.
Tag line font file (relative to /var/spool/hylafax) [etc/lutRS18.pcf]? Tag line format string ["From %%l|%c|Page %%p of %%t"]?	Tag lines are an optional feature that cause each page of an outbound facsimile to be marked with a line of text. A proper description of the tag line support is provided in the Tagline Configuration section of the next chapter.
Note that in the United States some form of identification of the sender of a facsimile is required by law; properly configured tag lines are an acceptable form of identification. Beware that the default tag line includes the phone number defined above; make sure this number is correct!
Time before purging a stale UUCP lock file (secs) [30]?	This parameter controls the time that a HylaFAX™ server process will wait before removing a UUCP lock file whose owner appears to be gone. The default parameter forces these stale lock files to be left around for just 30 seconds. This is an appropriate value to use on systems where applications that use UUCP lock files are known to be well behaved.
Percent good lines to accept during copy quality checking [95]? Max consecutive bad lines to accept during copy quality checking [5]? Max number of pages to accept in a received facsimile [25]? Syslog facility name for ServerTracing messages ["local5"]?	More parameters associated with inbound facsimile jobs; consult the section below.
The syslog facility controls where HylaFAX™ directs server tracing-related messages. By setting this parameter to a non-standard value HylaFAX™ messages can easily be recorded in a file separate from the normal system messages. Consult the Troubleshooting chapter, for more information.
Set UID to 0 to manipulate CLOCAL [""]? yes	This parameter should only need to be set on Silicon Graphics systems. Consult the section on IRIX-specific guidance for a description of why this parameter might be used.
The non-default server configuration parameters are: CountryCode: 1 AreaCode: 510 FAXNumber: +1 510 526-8788 LongDistancePrefix: 1 InternationalPrefix: 011 DialStringRules: etc/dialrules.sf-ba SessionTracing: 11 RingsBeforeAnswer: 1 SpeakerVolume: off GettyArgs: "-h %l dx_%s" LogFacility: local5 TagLineFont: etc/lutRS18.pcf TagLineFormat: "From %%l|%c|Page %%p of %%t" MaxRecvPages: 25 ClocalAsRoot: yes Are these ok [yes]?	This completes the collection of server-related parameters; the remaining steps identify and configure the modem for use. If the displayed parameters are unacceptable, typing something other than yes or a carriage return will cause faxaddmodem to prompt for new/changed parameter settings.
Setup modem-specific configuration parameters. faxaddmodem probes the modem to find out what type it is and what capabilities it has. The modem identity is then matched against a set of prototype configuration files to come up with modem-specific parameters that are appropriate to the modem and the style of flow control that is to be used between the host and modem. If the modem is not supported by an existing prototype configuration then faxaddmodem will prompt to get values for parameters.
Now we are going to probe the tty port to figure out the type of modem that is attached. This takes a few seconds, so be patient. Note that if you do not have the modem cabled to the port, or the modem is turned off, this may hang (just go and cable up the modem or turn it on, or whatever).
Probing for best speed to talk to modem: 38400 OK.	Use the -s option to avoid probing.
This modem looks to have support for both Class 1 and 2; how should it be configured [2]?	Modems that support multiple classes can be configured to use any supported class. By default Class 2.0 is considered better than Class 2 which is preferred over Class 1.
Hmm, this looks like a Class 2.0 modem. Modem manufacturer is "USRobotics Courier V.Everything". Modem model is "Product type US/Canada External".
DTE-DCE flow control scheme [default]?	The flow control scheme requested is one of xonxoff for software flow control, rtscts for hardware flow control, or default for a setting that is appropriate for the modem and the tty device.
Beware of using an improper flow control scheme for the selected tty device. On systems where faxaddmodem understands how tty device names reflect flow control characteristics, selecting a flow control scheme not supported by the device will cause faxaddmodem to prompt for confirmation and/or to change the device name or the flow control scheme.
Using prototype configuration file usr-2.0... The modem configuration parameters are: ModemFlowControl: rtscts ModemHardFlowCmd: AT&H1&I0&R2 ModemNoFlowCmd: AT&H0&I0&R1 ModemRate: 38400 ModemResultCodesCmd: ATQ0X4 ModemSetVolumeCmd: "ATM0 ATM1 ATM1 ATM1 ATM1" ModemSetupAACmd: AT+FAA=1 ModemSetupDCDCmd: AT&C1 ModemSetupDTRCmd: ATS13=1&D2 ModemSoftFlowCmd: AT&H2&I2&R1 Class2BUGCmd: AT+FBU=0 Class2CQQueryCmd: !(0),(0) Are these ok [yes]?	The modem-specific configuration parameters are obtained from prototype configuration files that reside in the config subdirectory of the HylaFAX™ spooling area. These parameters have been taken from working systems and should provide a functioning configuration based on the modem type and the selected flow control scheme.
If no prototype configuration file exists for a modem then faxaddmodem will prompt for settings. There are generic prototype configuration files for Class 1, Class 2, and Class 2.0 modems. Because there are many configuration parameters for modems it may be preferrable to use a normal text editor instead of faxaddmodem when constructing a configuration file for an unsupported modem, To do this simply accept the default parameters and then edit the generated configuration file before starting up a server for the modem. Once a working configuration file is created it is simple to create a prototype file from it; consult the faxaddmodem(1M) or hylafax-config(4F) manual pages for information on doing this.
Creating new configuration file /var/spool/hylafax/etc/config.ttyf2... Done setting up the modem configuration.
Checking /var/spool/hylafax/etc/config for consistency... ...everything looks ok; leaving existing file unchanged. Don't forget to run faxmodem(1M) (if you have a send-only environment) or configure init to run faxgetty on ttyf2.	At this point faxaddmodem compares the parameters setup for the modem against the parameters setup for the HylaFAX™ scheduler process. If any parameters are incompatible it prompts to see if they should be used to create a new file for the scheduler.

Starting Outbound Service

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

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

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

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

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.

Setting up Inbound Service

t2:23:respawn:/usr/local/sbin/faxgetty ttyf2

cua0	"/usr/local/sbin/faxgetty /dev/cua0"	dialup	on

In general it is desirable to run faxgetty because faxgetty informs the HylaFAX™ scheduler process whenever modems are in use and because it identifies modems' capabilities (passing them on to the scheduler so that it can make informed scheduling decisions). faxgetty also includes support for screening calls based on caller-ID information (consult the section ``Caller-ID Support'') and for automatically routing calls based on distinctive ring when these services are provided by the local PTT (consult the section ``Distinctive Ring Support'') . For this additional functionality, and because faxgetty does a reliable job of reseting and configuring recalcitrant modems, it may even be desirable to run faxgetty on non-fax modems.

The following sections discuss HylaFAX™ support for servicing particular types of inbound calls.

Facsimile Service

Data Service

Adaptive answer is the ability for a modem to determine whether an incoming phone call is for data, fax, or voice use. If a modem supports a good adaptive-answering facility then it should be enabled with the ModemSetupAACmd and the faxgetty process will automatically service fax, data, or voice calls as identified by the modem. Most Class 2 and Class 2.0 modems provide adaptive-answer support that distinguishes data calls from fax calls and the prototype configuration files that come with HylaFAX™ automatically enable it if it is provided by the modem. Most Class 1 modems do not provide adaptive-answer support, but HylaFAX™ provides adaptive-answer support in the server. Consult the section on ``Adaptive Answer Support'' in the next chapter for help on configuring adaptive-answer support.

Setting up the GettyArgs parameter requires an understanding of how to automatically startup the system getty program. HylaFAX™ will invoke the getty program when a data call is recognized and set up the standard input, output, and error descriptors to point to the appropriate tty device. The getty program should not reopen or reinitialize the modem before doing its work. Some getty programs are incapable of this and are unsuitable for use with HylaFAX™. The parameters passed to the getty program must also identify the speed to use to communicate with the local modem. Some getty programs want to automatically detect this rate based on the CONNECT message that a modem sends to the host when a connection is established; these programs are unsuitable for use with HylaFAX™. A getty program used with HylaFAX™ must be able to handle a fixed speed for host-modem communication, with the speed specified on the command line.

For System V-style getty programs the appropriate parameters are typically of the form:

GettyArgs: "-h %l dx_%s"

For BSD-style systems, GettyArgs is usually of the form:

GettyArgs: "std.%s -"

g|std.19200|19200-baud:sp#19200:
h|std.38400|38400-baud:sp#38400:

---

Setting up Client Access

hfaxd is normally started up when the faxsetup program is run. faxsetup also arranges for hfaxd to be automatically started up each time a server machine is booted; either standalone by a script invoked by the init process or indirectly by the inetd process. The preferred way to run hfaxd is in a standalone mode as this gives optimal performance.

When hfaxd is started the command line arguments specify which of several client-server protocols it should offer. hfaxd currently has support for three protocols:

• the Version 4.0 HylaFAX™ client-server protocol,
• the old HylaFAX™ client-server protocol used in versions prior to 4.0, and
• the Simple Network Pager Protocol (SNPP) that is used to submit alpha-numeric text pager requests.

# /usr/local/sbin/hfaxd -i 4559 -o 4557 -s 444

It is also possible to have the inetd program startup hfaxd. In this case only a single protocol can be requested since inetd advertises service and establishes the network connection. For example, the following entry might be used in the inetd.conf file to startup hfaxd to service SNPP requests:

snpp stream tcp nowait fax /usr/local/sbin/hfaxd hfaxd -S -d

It is possible to run hfaxd in a standalone mode as well as indirectly from inetd so long as this is done for separate protocols. Doing this however is of questionable value since it is much more efficient for a single standalone hfaxd process to support multiple protocols than to have multiple unrelated hfaxd processes.

Beware that hfaxd must either be started up by the super-user or be installed setuid-root for proper operation.

Besides arranging for hfaxd to get started up when a server machine is booted, it is necessary to specify which client machines and users can have access to a HylaFAX™ server machine. This is specified by the contents of the etc/hosts file in the HylaFAX™ spooling area on the server machine. The contents of this file is specified in the hosts(4F) manual page. The default etc/hosts file that comes with HylaFAX™ permits anyone to have access through the localhost network interface; i.e. the hosts file contains:

localhost
127.0.0.1

The etc/hosts file must be owned by the fax user and be mode 0600 or hfaxd will not permit client access.

Setting up Periodic Maintenance Work

The faxqclean program is responsible for removing old document and job description files from the spooling area on a server. These files are created when outbound jobs are created but are removed in a delayed fashion to permit clients to resubmit jobs without retransmitting all the information to the server and to allow imaged documents to be reused in unrelated facsimile transmissions. faxqclean is also responsible for archiving outbound jobs that have completed.

The faxqclean program in version 4.0 does not support job archiving; but consult the manual page to verify this (in case someone has done some local improvements).

faxqclean must be run by the super-user. A sample entry for the cron program that runs faxqclean once each hour might be:

0 * * * * /usr/local/sbin/faxqclean

25 23 * * * sh /usr/local/sbin/faxcron | mail FaxMaster

Modem Configuration Issues

AT+FCLASS=0DT<phone number>

Note that when HylaFAX™ places an outbound facsimile call it automatically forces the modem into Class 1, 2, or 2.0 before issuing ModemDialCmd. Thus the old FlexFAX trick of changing the class in the ModemDialCmd parameter should not be used.

System-specific Guidance

• IRIX:
  On Silicon Graphics Indigo and Indy machines you can not use a Macintosh modem cable to connect your modem to the DIN-8 connector on the back of your host. A Macintosh cable uses a special wiring pattern to pass the RTS and CTS signals between the host and modem. This wiring is not compatible with the wiring used on SGI machines. While it may appear that the the modem and cable work, hardware flow control will not function properly and data will eventually be lost. Consult the serial(7) manual page for an explanation of how to wire up modem cables.

  The tty device that is used must reflect whether hardware or software flow control is to be used. Under IRIX, modem devices (i.e. those that monitor DCD) come in two flavors: ttyf* devices support RTS/CTS flow control while ttym* devices support XON/XOFF flow control. If you want to use hardware flow control to communicate with your modem you should use a ttyf* device, otherwise use a ttym* device. If you fail to use the correct device you may still get the correct flow control (because later versions of IRIX actually permit flow control to be switched irrespective of the device used), but you are likely to collide with other modem users such as cu, uucp, ppp, and slip that still use the old-style device names (so UUCP lock files may be created for a different name than the one HylaFAX™ is using).

  USR modems work under IRIX 5.x only when patch 475 or a successor is installed and ClocalAsRoot is set to Yes in the modem configuration file.

  Versions of IRIX prior to 6.2 have a bug in the device driver for the on-board serial ports on several systems that causes RTS/CTS flow control to be turned off as a side effect of setting the CLOCAL flag on the associated tty device. Patch 475 (``RTS/CTS flow control busted when CLOCAL is set'') and its successors correct this problem and must be installed to use HylaFAX™ with RTS/CTS flow control (install the appropriate successor to patch 475). Also, when this patch is installed the ClocalAsRoot modem configuration parameter must be set to Yes for proper operation (see hylafax-config(4F) for a detailed explanation of what this parameter does). If you do not have the appropriate patch installed on your system then you will either see flow control-related problems when transmitting facsimile or possibly some other problems related to modems dropping DCD when carrier is lost.

  The DPS-based PostScript imager program distributed with HylaFAX™ is available only in COFF format. Because IRIX 6.2 does not support COFF executables this program cannot be used with HylaFAX™. A Ghostscript-based RIP should be used under IRIX 6.2.

  The font metric files required by client applications are contained in the dps_eoe.sw.dpsfonts image that is part of the standard IRIX distribution.

• SCO:
  The standard SCO serial I/O driver (SIO) does nothing with modem control lines if CLOCAL is set on the tty device. The usual workaround is to use the FAS driver instead.
• Solaris:
  Versions of Solaris prior to 2.5 require a patch to correct the handling of RTS/CTS flow control with serial ports built around the Zilog ZS8530 chip.

  Some versions of Solaris (2.3 is known to do this) silently truncate or discard syslog messages longer than about 120 characters.

  Use the /dev/cua/* devices and not the /dev/term/* devices.

  When using ttymon to service inbound data calls set the GettyArgs parameter to something like the following:

  GettyArgs: "-g -h -d /dev/cua/a -l 38400 -m ldterm,ttcompat"

  Be certain you are not running a ttymon with sac when using HylaFAX™. Disable all ports that are to be used by HylaFAX™ with admintool or pmadm(1m).

• SunOS:
  Versions of SunOS prior to 4.1.4 require a patch to correct the handling of RTS/CTS flow control with serial ports built around the Zilog ZS8530 chip. These patches are available at:
  • ftp://sunsolve1.sun.com/pub/patches/100513-05.tar.Z for SunOS 4.1.[123], and
  • ftp://sunsolve1.sun.com/pub/patches/101621-04.tar.Z for SunOS 4.1.3_U1.
  (choose the one appropriate to the system you are running).
• SVR4:
  The following GettyArgs: configuration parameter is suitable for many SVR4-based systems:

  GettyArgs:	"-g -h -t 60 -l ff_%s"

  Be sure entries for different baud rates are defined in the /etc/ttydefs file.
• Ultrix:
  [Ed: Thanks to Albert DeKnuydt for the following advice.]
  
  1. As Ultrix has a brain-damaged shell, the command /bin/sh ./configure does not work properly. You should use instead /bin/sh5 < configure .
  2. The archaic syslog facility should be upgraded from ftp://gatekeeper.dec.com/pub/DEC/jtkohl-syslog-complete.tar.Z.
  3. Ultrix lacks some functions in the c library, and needs to linked to libiberty.a as well. After configuration, change the line in the defs file from

     MACHDEPLIBS = -lm -lmalloc

     to

     MACHDEPLIBS = -lm -lmalloc -liberty

     Libiberty is available with the gcc compiler.
  4. Ultrix header files violate ANSI rules so you have to tell gcc 2.95 (and later) to allow this with the added line in the defs file :

     LC++OPTS = -fpermissive

  5. Interrupt handling is out of date, and cannot claim to be compatible with SV_INTERRUPT. Add the following line to port.h after configuration :

     #undef SV_INTERRUPT

  6. Most (all?) DEC mips machines do not completely support serial port speeds above 19200.

Advanced server configuration.

HylaFAX™ table of contents.

Last updated $Date: 2002/05/03 00:46:46 $.