[hylafax-users] partial incoming faxes not being e-mailed

[marthter <marthter@xxxxxxxx>]

marthter wrote:

Lee Howard wrote:
  

marthter wrote:

    

a Rockwell modem of some kind:

ati0 14400 [OK]
ati1 007 [OK]
ati2 [OK]
ati3 V1.620-BP39 ROCKWELL RPI (TM) MODEM [OK]

About once or twice per month, the incoming modem gets stuck and
keeps the phone off hook indefinitely.  When this happens, faxstat
shows it thinks it is still receiving, even though this might have
been several hours ago:
      

If I restart hylafax (including faxgettys) it is stuck "Initializing
server" seemingly indefinitely (I waited 20+ minutes).  The lock file
is there with the process ID of the new faxgetty, so I don't think it
is a problem of old lock files.  The only way I've found to clear it
is reboot the machine.

I had been limping along with a USR in that receiving slot for
several years.  About 6 months ago (feeling guilty about asking this
list (esp. Lee) for more help than that modem deserved) I switched it
for the above modem.  This (or a similar) problem was happening with
that USR modem too, so that leads me to believe it isn't modem specific.

The log file of the last incoming session is attached.  Anyone have
any suggestions on what might be going wrong, or how to remedy it?
      

The log file indicates pretty much the same thing that you're telling
us here: that the modem firmware has locked up.  To verify that
HylaFAX has concluded this correctly, you should (when this happens)
disable faxgetty and then run minicom on the modem and try to "wake"
it up.  (Maybe try "ATZ" or "AT&F" or just plain "AT".)

If you can't wake it up, then the modem apparently will need to be
power-cycled to wake it up.  This will require a reboot if it is an
internal modem.

I don't think that the USRs and this had a common problem... unless
you have some other hardware sharing IRQ 3.  Normally, however, I've
not known USRs to lock up like this very often.  They do crash, yes,
but they reset themselves when they do.  It may be some kind of serial
misconfiguration of some kind, too.  But most probably it's a firmware
issue.  After all, the modem is probably 12 years old now.

Lee.

    

Replying to an old 2005 thread of my own.  On this same computer, still
RH9, and same modem, which would be like 14 years old now, this is still
happening.  On May 15, I upgraded to the latest hylafax 4.3.4 (from
source), and that didn't help either.

Any suggestions on how I could further investigate or rule out the IRQ 3
sharing?

Hopefully I'll be able to try the minicom suggestion above next time it
happens, but usually I just need to reboot it ASAP to get access to the
phone line back (it is also the voice line, fax is on a distinctive ring
number).  Would someone picking up the line to try to make a voice call
explain this possibly?

It is really just at the threshold of annoyance (obviously I've been
tolerating the occasional need to reboot for 2 years now) but I thought
I'd take another stab at it.  I guess my next try after this will be new
OS install with same hardware (that's overdue anyway), and then maybe
swapping to some other motherboard if I can find one around, and then
removing, stomping on, and burning the modem.

I've got 2 logs this time, one from a failed incoming attempt, and one
from a successful one shortly thereafter from the same sender (probably
the same fax content too).

Any comments appreciated.
  

One other thing, probably more related to the recent upgrade, not related to the modem problem, is that failed incoming faxes (like the failed one for which I gave the log in the previous "modem stuck in receiving state" e-mail) do not send the partial pages by e-mail.

I tried running the faxrcvd command as found in the log files, from the /var/spool/hylafax directory, once with the arguments as seen in the successful log, and once is seen in the failed log:


[root@socrates hylafax]# bin/faxrcvd "recvq/fax000003389.tif" "ttyS0" "000262394" ""
FILE 1: recvq/fax000003389.tif
Converting recvq/fax000003389.tif to PDF
Using tiff2pdf
[root@socrates hylafax]#




[root@socrates hylafax]# bin/faxrcvd "recvq/fax000003388.tif" "ttyS0" "000262349" "T.30 T2 timeout, expected signal not received"
bin/faxrcvd: line 194: /usr/sbin/sendmail: Argument list too long
bin/faxrcvd: line 1: /usr/bin/dirname: Argument list too long
bin/faxrcvd: line 434: /bin/sed: Argument list too long
bin/faxrcvd: line 435: /bin/grep: Argument list too long
bin/faxrcvd: line 320: /bin/cat: Argument list too long
bin/faxrcvd: line 408: /bin/gawk: Argument list too long
bin/faxrcvd: line 349: /bin/cat: Argument list too long
bin/faxrcvd: line 1: /usr/bin/expr: Argument list too long
bin/faxrcvd: line 644: [: -le: unary operator expected
FILE 1: recvq/fax000003388.tif
Converting recvq/fax000003388.tif to PDF
Using tiff2pdf
bin/faxrcvd: line 1: /bin/basename: Argument list too long
bin/faxrcvd: bin/tiff2pdf: /bin/bash: bad interpreter: Argument list too long
bin/faxrcvd: line 1: /bin/basename: Argument list too long
bin/faxrcvd: line 1: /usr/bin/dirname: Argument list too long
bin/faxrcvd: line 174: /usr/sbin/sendmail: Argument list too long
bin/faxrcvd: line 434: /bin/sed: Argument list too long
bin/faxrcvd: line 435: /bin/grep: Argument list too long
bin/faxrcvd: line 349: /bin/cat: Argument list too long
bin/faxrcvd: line 408: /bin/gawk: Argument list too long
bin/faxrcvd: line 320: /bin/cat: Argument list too long
bin/faxrcvd: line 669: /bin/rm: Argument list too long
[root@socrates hylafax]#



This machine is still on Redhat 9, so could this be because the versions of all these utilities are older versions with different command line syntaxes than what is expected now?  If so, does that mean the configure command should catch this or something?


Regards.

Martin