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.
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.
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.
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.
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.
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.
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.
DO_CHAT_SEND_DELAY and FAX_COMMAND_DELAY in
policy.h.
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.
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.
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 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...)
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
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