mgetty + sendfax

Go to the first, previous, next, last section, table of contents.

Problems common to many modem types

Disable auto-answer in the modem (ATS0=0), because it will interfere with the manual answer done by mgetty. If you have to use auto-answer, set the mgetty ring-counter (-n <i>) high enough that mgetty will never try to answer the phone manually.
Make sure that your modem is set to return verbose result codes, that is, set ATV1. Otherwise, the modem won't return `CONNECT' or `RING' but `1' or `2' as result code, and mgetty definitely doesn't understand that. By default, mgetty sets ATV1 automatically, but if you change the init sequence, watch out for this.
Make sure that your modem is set to the proper dialing type (ATT&W for touch-tone, ATP&W for pulse dialing) -- sendfax uses ATD... to dial out, assuming that the modem knows which dialing method to use. Alternatively, set FAX_DIAL_PREFIX in `policy.h' or dial-prefix in `sendfax.config' accordingly.
If the default modem initialization string in `policy.h', which is quite generic, doesn't work for your modem, you can either change it according to your needs, or store all settings in the non-volatile RAM (NVRAM) inside the modem and change the initialization strings to plain ATZ (modem reset). These settings ought to work with most modems: ATS0=0: do not auto-answer, E1: echo on, Q0: send modem responses, &D3: reset on DTR->low. The following, for example, are ZyXEL specific things: &H3: set handshake to RTS+CTS, &N0: "multi-auto" connect, accept all known protocols, &K4: enable v42bis/mnp5 compression. Naturally, you can use any init string you want (but the modem has to return OK) -- check with your modem manual.
On USR and some ELSA Modems, it has occasionally been reported that the initialization phase runs through fine, but incoming RING messages are not recognized, and mgetty complains about `junk on the line'. In all those cases, it were baud rate problems. The modem was initialized with an init-sequence of "" ATZ OK only. Problem with this is, after ATZ, the modem changes to the DTE baud rate that the last AT&W command was sent with. If that baud rate differs from the mgetty port speed, a RING won't be detected. Fix is easy: send another AT command after the ATZ. For example, make the init sequence "" ATZ OK AT OK. The second AT command will set the modem back to the mgetty port speed.
Some modems do not like the `+FDCC=1,5,...' command. In the latest version, mgetty and sendfax will automatically detect if the modem isn't able to do 14400 bps for faxing and will use 9600 bps --- `+FDCC=1,3,...' -- instead. So don't worry about the error message.
Sometimes mgetty cannot initialize the modem, it times out waiting for the first `OK'. (USR Sportsters are known to hit this). I assume that the problem is the DTR-induced modem reset before sending the first `+++ATH' to the modem. I know that some modems need quite a lot time after a reset, so this should go away if you add more delays before sending the first string to the modem: In `conf_mg.c' (line 38 or so) change
```
char *def_init_chat_seq[] =
           { "", "\\d\\d\\d+++\\d\\d\\d\r\\dATQ0V1H0", "OK",
```
to
```
char *def_init_chat_seq[] =
           { "", "\\d\\d\\d\\d\\d\\d+++\\d\\d\\d\r\\dATQ0V1H0", "OK",
                   ^^^^^^^^^ additional delays here
```
Or, if you don't want to modify the code, just set the init-chat sequence in `mgetty.config' accordingly. Alternatively, you can just switch off the toggling of DTR (since the HUPCL flag is set, it should work as well) by setting toggle-dtr no in `mgetty.config'.
Some operating systems send their commands too fast for some modems (Linux is known to do this). In that case it may be necessary to increase the delay times for DO_CHAT_SEND_DELAY and FAX_COMMAND_DELAY in `policy.h'.
Some Modems toggle DCD between pages, possibly correlated to the presence of the "high speed" page transmission carrier. sendfax normally runs carrier-sensitive, and will then get a lot error messages in the read and write calls, logging them as I/O Error or something similar when sending the first or second page. To work around this, set ignore-carrier true in `sendfax.config'. If you run into this problem, sendfax will complain about `Error +FHNG:-5 (Unexpected hangup / read() error / write() error)' and abort.
Some modems do not understand ATH0, responding with `ERROR' to that. Just modify the init-chat setting in `mgetty.config' to send ATH instead of ATH0. This will fix it.
Faxing to some modems works very well, faxing to "normal" fax machines fails all the time. In most cases, this error is caused by badly created G3 files. If you use the old pbm2g3 program, or an old copy of hp2hig3, it will cause bad G3 files. Recently, a new problem appeared for postscript files created by certain programs that insist on setting their ideas of the page size (some versions of WinWord, FrameMaker, and dvipsk). If used together with ghostscript 3.*, the resulting G3 file's width isn't correct. For a fix, try creating the postscript file with a different program, use a newer version of ghostscript, or an older one (2.62 is fine). Quite often it helps to add -sPAPERSIZE=a4 to Ghostscript's command line (in faxspool). With a mgetty version later than June 1996, the g3cat program should take care of this problem, fixing the line width on-the-fly. It will print a warning, to tell you about the problem, though. So if you get this warning, faxing should work, but you'd better check all your programs anyway.
Some other Modems cannot (or not properly) distinguish between calling faxes and calling modems. Some of them just refuse to answer both, only recognizing one and failing on the other (NO CARRIER) -- in that case, there's nothing you can do to make it receive both (except making the manufacturer fix it). What you can do is to force it to receive always fax or always data (what is more important for you). Data-Only can be set by the data-only keyword in the configuration file, and Fax-Only with the fax-only keyword. In some cases, those problems may be caused by the modem forgetting the AT+FAA=1 command if it receives any other command after it. To fix it, it may help to change the "answer chat command" in the config file to
```
answer-chat "" AT+FAA=1;A CONNECT \c \r
```
if this helps for your modem, please tell me so, and I'll include it into the documentation. Some other modems can distinguish the different call types most of the time, but some 2400 bps modems mysteriously fail. That may be caused by some -- strange -- modems sending a certain tone when calling the other side, and the receiving end mistaking that for the fax calling tone. Arne Marschall said about that: "...Or try calling your modem with your phone and whistle. If it says "+fcon" it is one one those which can't deal with modems using a calling tone" - try it. Another, quite simplistic approach of some modem manufacturers is that they distinguish Fax by waiting until the time specified in register S7 (time to carrier) runs out, and then switching from data to fax carrier. That normally works quite well - if the other side is patient enough to wait that long .... For example, if the modem switches to fax after 60 seconds have passed, and the caller has a timeout of 50 seconds, it will definitely fail. If in doubt, try setting ATS7=30 (but only if all else fails - and don't ask me why it doesn't work...)
Except if you feel sure that your modem needs less, do not try to send or receive faxes with a port speed of less than 19200 bps. Since fax transmission is synchronous (no start and stop bit!), you need at least 12000 bps on the Computer-Modem line to transmit 9600 bps on the line.

For some modems, incoming faxes are detected properly, but mgetty times out about two minutes later in fax_wait_for(OK). Most likely, the switchbd (`mgetty.config') speed is set wrongly. A number of cheap modems (e.g. Rockwell-Chip based ones) step to 19200 bps upon fax reception, and setting this option to `19200' will tell mgetty about it. Better modems have no need for that, so if you have defined it and your modem does *not* change bit rates, it won't work either. If you have this problem, your log file for an incoming fax call will look like this:

09/21 09:55:48 yS1  waiting for "RING"
09/21 09:55:48 yS1  got: [0d][0a]RING ** found **
09/21 09:55:48 yS1  send: ATA[0d]
09/21 09:55:48 yS1  waiting for "CONNECT"
09/21 09:55:48 yS1  got: [0d][0a]ATA[0d][0d][0a]FAX
09/21 09:55:50 yS1  found action string: "FAX"
09/21 09:55:50 yS1  start fax receiver...
09/21 09:55:50 yS1  fax receiver: entry
09/21 09:55:50 yS1  fax_wait_for(OK)
09/21 09:55:56 yS1  fax_wait_for: string '+FCON'
09/21 09:57:50 yS1  Warning: got alarm signal!
09/21 09:57:50 yS1  fax_read_byte: read returned -1: Interrupted system call
09/21 09:57:50 yS1  fax_get_line: cannot read byte, return: Interrupted system call

For a couple of modems, you can find initialization and setup hints in the file `doc/modems.db'. Just browse through it, maybe you'll find something helpful. (You're welcome to provide entries for modems not yet in the list).
Sometimes, very weird things happen upon login (that is, long after mgetty has done its work), for example, /bin/login blocks infinitely, the caller is thrown out immediately again, or the shell won't notice a logout, etc. Quite often, this is caused by a modem not setting the data carrier detect (DCD) line properly (properly meaning here "reflecting the actual line conditions"). On most modems this is done with the AT&C1 command. Another possibility are too long or otherwise broken modem cables that corrupt the signals, and introduce noise on the modem control lines. Flat cables are famous for this, use round, shielded modem cables, no longer than necessary.
mgetty will complain loudly if you switch off your modem. Well, what should I say, this is a feature :-) -- I think that mgetty should detect and complain if a modem is not working, and if you switch it off, it is most definitely not working. For most modems, there is an easy way out. mgetty can query the modem's DSR line at startup, and wait until that line comes active. For that to work, you need to set DSR to "always on" with AT&S0&W (entered from a terminal program), and then switch on need-dsr yes in `mgetty.config'. Check the log file (with debug 6) to see whether it's working. It won't work for old unix systems where you can't query the state of the serial port control lines (DSR, DCD, etc.). For modems or unix systems that have problems with DSR, there's another approach: You just create a file, `/etc/nomodem.ttyS1', or however you want to name it, when you intend to switch off your modem. Instead of running mgetty from `/etc/inittab', you run a "wrapper" script that will wait until the nomodem file disappears, and then starts mgetty. That way, you can just prevent mgetty from starting when you don't want it to. The wrapper is easy:
```
#!/bin/sh
#
while test -f /etc/nologin.ttyS1
do
   sleep 60
   done
exec /usr/local/sbin/mgetty ttyS1
```
I have been asked about "superfine" fax mode recently (using 392/408 dpi instead the usual 198/204 dpi). It is not yet implemented. It would not be not overly hard, but you need a modem that supports it - no class 2 modems that I know of support it, and only very few 2.0/2.1 modems (MultiTech). So it hasn't been done yet.
Similar to the last bullet, V34 fax (using transfer speeds up to 28.800 bps) isn't fully implemented yet. My modems do not support it, and nobody has asked for it yet. It should be really easy, though.

Go to the first, previous, next, last section, table of contents.