|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] Can send, but can't receive
On 2003.11.29 18:09 Michael Evans wrote:
I've been experimenting with hylaFAX on and off for a while, trying
to get it to work with the following:
Pentium II, 450 MHz, 128Mb RAM
SuSE 7.3
Zoom 2920 PCI modem (Lucent chipset)
On Nov. 28, I got the latest hylafax sources from CVS and built and
installed them.
I use current CVS on a number of production servers with modems in
Class 1. I even have a Zoom 2920 on a receive-only line on one of them.
There's a feature that lets you limit the Class 1 sending and
receiving speeds by substituting your own string for the available
speeds reported by the modem in response to the AT+FTM=? and AT+FRM=?
commands. Once I've limited the modem to 4800 bps, sending works
great.
Why do you have troubles with higher speeds?
However, when the modem's phone number is called, it doesn't seem to
get to the speed negotiation part:
Nov 29 17:23:39.88: [ 938]: SESSION BEGIN 00000108 16264494440
Nov 29 17:23:39.88: [ 938]: HylaFAX (tm) Version 4.1.6
Nov 29 17:23:39.88: [ 938]: <-- [4:ATA\r]
Nov 29 17:23:46.01: [ 938]: --> [7:CONNECT]
Nov 29 17:23:46.01: [ 938]: ANSWER: FAX CONNECTION DEVICE
'/dev/ttyS4'
Nov 29 17:23:46.01: [ 938]: MODEM input buffering enabled
Nov 29 17:23:46.01: [ 938]: RECV FAX: begin
Nov 29 17:23:46.01: [ 938]: MODEM input buffering disabled
Nov 29 17:23:46.01: [ 938]: <-- HDLC<32:FF C0 04 AD 00 55 12 9E 36
86 62 82 1A 04 14 2E B6 94 04 6A A6 4E CE 96 F6 76 04 2C 74 8C 74 6C>
Nov 29 17:23:46.01: [ 938]: <-- data [32]
Nov 29 17:23:46.01: [ 938]: <-- data [2]
Nov 29 17:23:46.02: [ 938]: --> [7:CONNECT]
Nov 29 17:23:46.02: [ 938]: <-- HDLC<23:FF C0 02 74 C6 76 92 04 34
16 2E 96 B6 CA 04 64 04 86 EE 86 E6 F6 2A>
Nov 29 17:23:46.02: [ 938]: <-- data [23]
Nov 29 17:23:46.02: [ 938]: <-- data [2]
Nov 29 17:23:46.02: [ 938]: --> [7:CONNECT]
Nov 29 17:23:46.03: [ 938]: <-- HDLC<10:FF C8 01 00 77 5F 01 79 FB
C0>
This DIS signal indicates that you are supporting V.27ter, V.29, and
V.17. Are you not limiting your receiving speeds?
Nov 29 17:23:46.03: [ 938]: <-- data [10]
Nov 29 17:23:46.03: [ 938]: <-- data [2]
Nov 29 17:23:48.17: [ 938]: --> [2:OK]
Nov 29 17:23:48.17: [ 938]: <-- [9:AT+FRH=3\r]
Nov 29 17:23:48.27: [ 938]: --> [7:CONNECT]
Nov 29 17:23:49.97: [ 938]: --> HDLC<25:FF C0 C2 0C 2C 2C 2C 9C 2C
2C 6C 4C 6C 04 04 04 04 04 04 04 04 04 04 7B D6>
Nov 29 17:23:49.97: [ 938]: --> [2:OK]
Nov 29 17:23:49.98: [ 938]: REMOTE TSI "6264494440"
Nov 29 17:23:49.98: [ 938]: <-- [9:AT+FRH=3\r]
Nov 29 17:23:49.99: [ 938]: --> [7:CONNECT]
Nov 29 17:23:50.33: [ 938]: --> HDLC<11:FF C1 00 45 1F 01 01 01 00
CC D3>
Nov 29 17:23:50.33: [ 938]: --> [2:OK]
The modem has a problem. It should have responded ERROR and not OK
because the CRC on that frame doesn't check out. Set
Class1ValidateV21Frames to "yes" in your modem config file and you will
see this. (The modem firmware is supposed to check frames, so the
software shouldn't have to, but something seems wrong with your modem.)
Nov 29 17:23:50.33: [ 938]: HDLC frame with bad control field 0xc1
A control field is either 0xC0 or 0xC8, so if the previous frame were
actually valid, then a control field of 0xC1 would be bogus and we
could point a finger at the remote system. In this case something's
wrong with your modem.
Nov 29 17:23:50.33: [ 938]: DELAY 1500 ms
Nov 29 17:23:51.83: [ 938]: <-- [9:AT+FTH=3\r]
Nov 29 17:23:54.83: [ 938]: --> [0:]
Nov 29 17:23:54.83: [ 938]: MODEM TIMEOUT: sending HDLC frame
And your modem seems to be locked at this point and hereforward...
It always chokes on that one HDLC frame with the "bad control field
0xc1". It does this regardless of which machine is placing the call
(machines calling from different phone numbers). After "SESSION END"
, when the log file is completed, the modem is no longer able to
answer any calls. Any subsequent callers just hear the phone ringing
endlessly, with no answer (and no busy signal). If I query the
hylafax server with WHFC, it reports "receiving facsimile" instead of
the usual "running and idle." The only way to make the modem usable
again is to stop hylafax, issue the "faxquit" command, kill the
faxgetty process, and then restart hylafax.
Exactly... your modem seems to have become unresponsive.
Meanwhile, depending on his machine, the sender gets a "NG - Poor
Line Condition" error message or something similar, and his machine
hangs up.
I wouldn't put too much faith in this diagnostic. But, to your
knowledge are the line conditions poor?
In searching through the message logs, I got a hint that this might
be due to an outdated libtiff (I had v. 3.4), so I went to
libtiff.org and got the latest version, v 3.6. But building and
installing the latest version over the old one didn't help.
libtiff has nothing to do with this.
I would venture to guess that either you are having modem hardware
failures, something is wrong with the kernel serial driver on your
system, or some other hardware or software is interfering with the
modem (i.e., bad motherboard, etc.).
The easiest thing to do may be to try another modem on one of the
external serial ports (provided that you have an external serial modem
to use).
Lee.
____________________ HylaFAX(tm) Users Mailing List _______________________
To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
*To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxxxxx*
