Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

Mgetty+Sendfax with Vgetty Extensions (FAQ)
Section - Troubleshooting questions & answers

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]

Top Document: Mgetty+Sendfax with Vgetty Extensions (FAQ)
Previous Document: Why mgetty ignores /dev/tty* dialin, /dev/cua* dialout conventions:
Next Document: Programs generating "invalid" Postscript that can't converted to the G3 format for sendfax
See reader questions & answers on this topic! - Help others by sharing your knowledge

Q: I keep getting the error code +FHNG:50 or +FHNG:54 after sending a
   page. Sometimes it says "page bad, retrain requested" and infinitely
   resends the page.

A: This error means that something went wrong between the two machines,
   while your end was sending the page data. In the case of +FHNG:50 or
   +FHNG:54, the other end most likely simply hung up (so your modem
   couldn't get any page transfer status at all), in the other case, the
   receiver complained that it didn't like the data on the page.

   The most common reason for this behaviour is that you used a copy
   of ``pbmtog3'' that came from the ``pbmplus'' distribution and doesn't
   have my patch included (Mind you, the pbmtog3 program is required for
   the page headers that faxspool puts on top of each page!).

   If that is not the reason, there may be flow control problems, or the
   line have simply has been very noisy, or so. Get in touch with the
   receiver, and find out whether the page looks good or whether there are
   lines missing, others corrupted, ... - if there are errors, check your
   flow control setting.

   If there are no errors whatsoever, and you're sure that you use my
   version of pbmtog3 (called pbm2g3 or a patched version of pbmplus', 
   then I'm out of wits - something's broken in the modem. Maybe you 
   should upgrade your ROM version.

Q: When receiving faxes, I get the +FCON message logged, then mgetty says
   "starting fax receiver". fax_wait_for(OK) is called, logs some random
   junk bytes, and gives up after a minute, complaining about "timeout".

A: Most likely, you have a modem that switches baud rate to 19200 bps
   right after sending the +FCON message to the host, and the normal port
   speed is something else. Check policy.h whether FAX_RECEIVE_SWITCHBD
   is defined, and change the setting (if the modem does *not* change
   speed, but the define is *set*, the effect will be similar).
   Better yet, with the runtime configurable stuff, is to add the entry
   switchbd <nnn>" in mgetty.config

Q: I keep changing values in policy.h, but nothing changes.

A: maybe you've had an older version of mgetty installed to
   /usr/local/bin/mgetty and are calling this from /etc/init? Newer
   versions are installed in /usr/local/sbin/mgetty. Check the time
   stamp on the mgetty you just compiled vs. the mgetty listed in

Q: Half of the faxes that I receive are too short, they look as if every
   second pixel line is missing.

A: Well, they *are* short: most likely, they are received in normal
   resolution (204x98 dpi) instead of fine resolution (204x196 dpi). You
   can see it in the filename, if it starts with "ff*", it's fine, if it
   starts with "fn*", it's normal resolution. To ``stretch'' a normal
   resolution fax to proper proportions, use ``g32pbm -stretch fn...''

Q: login complains with ``no utmp entry, must execute login from the
   lowest level sh''

A: I *told* you not to fiddle with the ``utmp'' field... - most likely,
   in your ``login.config'' file, the utmp field for the entry calling
   /bin/login isn't "-".

   Another reason could be a faulty /etc/init (hits only Linux users) or a
   corrupted /etc/utmp file. In that case, reboot your machine.

Q: When mgetty is running and I dial out, I do not get "CONNECT" but only
   junk, as "+FCO", "+FTI:", "+FHS:20"

A: Well, yes, that's a problem with the 2.0 implementation in mgetty. That
   is: while mgetty is running, the modem is in "AT+FCLASS=2.0" mode and
   expects to connect to a fax on the remote side. (With class 2, we
   worked around this by setting +FCLASS=0;+FAA=1, but that will make the
   modem answer in class 2, not 2.0 [subject to further testing!])

   Solution: in the program dialing out, initialize the modem with
   "AT+FCLASS=0".  Most likely, a modem reset (ATZ) will also help.

Q: every time mgetty starts up, the permissions of my tty device get
   changed and I have to issue "chmod +w /dev/ttySx" to be able to
   dial out.

A: that's not a bug, that's a feature. You don't *want* to allow anybody
   using your machine to be able to dial out (think of your phone costs!),
   so it's a security issue.
   If you *want* to allow dialout for everyone, #define FILE_MODE 0666
   in policy.h. I would not recommend it, I would give access to a
   special group, and put every one that may dial out into this group.

Q: I have a Linux system, and while trying to dial out on /dev/cua1
   (mgetty is running on /dev/ttyS1), it says "device busy" (EBUSY)???

A: use the same device (always!!) for dial-in and dial-out.
   On Linux, use /dev/ttySx, on SunOS and *BSD use /dev/cuax.

Q: If I create a fax file with "gs -sDEVICE=dfaxhigh ..." and send it with
   sendfax, everything works *great*. If I run it through "faxspool", the
   receiving side reports an error. Is the "g3cat" program broken?

A: No, g3cat isn't the problem. The real problem is "pbmtog3", and I bet
   you have the pbmtog3 program from the pbmplus distribution installed.
   This program is *broken* (patch is in mgetty/patches/pbmtog3.p1), that
   is, it doesn't create proper T.4/G3 fax data. Thus, the receiving fax
   machine will get a fax that has some corrupt lines (the page header)
   and will complain about it.
   Patch pbmtog3, or use mgetty's pbm2g3. It's faster anyway.

Q: mgetty doesn't accept FidoNet calls. I get log entries like this:

     10/30 01:54:54 ##### data dev=ttyS1, pid=3401, caller=none,
     conn='38400/V32b 14400/V42b', name='', cmd='/bin/login',

   or this:

     10/30 05:31:03 ##### data dev=ttyS1, pid=7238, caller=none,
     conn='38400/ZyX  16800/V42b', name='', cmd='/bin/login', user='q.q.q.'

A: did you compile mgetty with -DFIDO defined? I don't think so. If
   -DFIDO isn't set, mgetty doesn't know about fido.

Q: Some of my programs use binary lockfiles and some use ASCII
   lockfiles.  Why does mgetty complain?  Can't it recognize both?

A: Mgetty complains because your system configuration is _wrong_.
   These error messages are there to help the system administrator
   notice a *severe configuration error* on his site.

   If all programs would understand both types of Locking, the
   messages would be silly, but since kermit usually simply ignores
   ascii locks, and uucico does so for binary locks, the situation is
   *highly* error-prone, and sysadmins should *SEE* this.

   Recompile your applications that use the modem so that all agree on
   the lockfile types.

Q: My modem and I share one phone line. Now I answered the phone
   and a modem greets me. How can I make mgetty take over?

A: Send the signal SIGUSR1 to the mgetty process. It will then answer
   the phone.

Q: I can fax only one page, then I get an error

A: When you see something like this in your log:
  > 03/22 19:15:58 yS1  fax_wait_for: string 'OK'** found **
  > 03/22 19:15:58 yS1  fax_send: 'AT+FET=0'
  > 03/22 19:15:58 yS1  fax_wait_for(OK)
  > 03/22 19:15:58 yS1  fax_read_byte: read returned 0: Unknown error
  > 03/22 19:15:58 yS1  fax_get_line: cannot read byte, return: Unknown error
  > 03/22 19:15:58 ##### failed transmitting f1.g3: +FHS:-4, time=55s
  you should define FAX_SEND_IGNORE_CARRIER in policy.h and recompile
  your binaries. There are some modems that drop the DCD line between
  pages. Alternatively, you can define ''ignore-carrier true'' in your
  config file.

Q: The message "WARING: DSR off - modem turned off or bad cable?" keeps
   showing up in the mgetty logfile.

A: If you see this message, it basically means that mgetty can't get
   the status of dsr (data set ready). This can be because the cable
   is bad or because you are using mgetty on solaris. Solaris doesn't
   give you the status of dsr. If you are running mgetty on a different
   platform, you might consider checking your cable or the modem

User Contributions:

Comment about this article, ask questions, or add new information about this topic: