Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] Too often COMREC invalid response received error
On 2003.12.17 07:59 Sedat wrote:
I have just setup a new faxserver on RH8.0 with
hylafax-4.1.8-1rh8.i386.rpm
running on a multitech PCI internal modem in class 1.
About 2 of every 3 fax reception fails with an "COMREC invalid
response
received" error.
Flow control is rtscts.
What could be the problem?
Here is the session log for a failed fax reception
Dec 16 15:18:34.93: [ 1156]: SESSION BEGIN 000000067 902122920744
Dec 16 15:18:34.93: [ 1156]: HylaFAX (tm) Version 4.1.8
Dec 16 15:18:34.93: [ 1156]: <-- [4:ATA\r]
Dec 16 15:18:43.92: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:43.92: [ 1156]: ANSWER: FAX CONNECTION DEVICE
'/dev/ttyS4'
Dec 16 15:18:43.92: [ 1156]: STATE CHANGE: ANSWERING -> RECEIVING
Dec 16 15:18:43.92: [ 1156]: MODEM input buffering enabled
Dec 16 15:18:43.92: [ 1156]: RECV FAX: begin
Dec 16 15:18:43.93: [ 1156]: MODEM input buffering disabled
Dec 16 15:18:43.93: [ 1156]: <-- HDLC<23:FF C0 02 4E A6 6E 4E A6 CE 1E
86 62
04 A6 36 A6 46 96 D2 04 04 04 04>
Dec 16 15:18:43.93: [ 1156]: <-- data [23]
Dec 16 15:18:43.93: [ 1156]: <-- data [2]
Dec 16 15:18:43.93: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:43.93: [ 1156]: <-- HDLC<10:FF C8 01 00 77 5F 01 79 03
C0>
Dec 16 15:18:43.93: [ 1156]: <-- data [10]
Dec 16 15:18:43.93: [ 1156]: <-- data [2]
Dec 16 15:18:45.14: [ 1156]: --> [2:OK]
Dec 16 15:18:45.14: [ 1156]: <-- [9:AT+FRH=3\r]
Dec 16 15:18:45.68: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:47.36: [ 1156]: --> HDLC<25:FF C0 C2 8C 8C 8C 2C 8C 2C 6C
04 4C
6C 4C 04 0C 9C 04 04 04 04 04 04 AC 6D>
Dec 16 15:18:47.36: [ 1156]: --> [2:OK]
Dec 16 15:18:47.36: [ 1156]: REMOTE TSI "90 262 6414111"
Dec 16 15:18:47.36: [ 1156]: <-- [9:AT+FRH=3\r]
Dec 16 15:18:47.37: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:47.63: [ 1156]: --> HDLC<9:FF C8 C1 00 45 1F 00 64 CB>
Dec 16 15:18:47.63: [ 1156]: --> [2:OK]
Dec 16 15:18:47.63: [ 1156]: REMOTE wants 14400 bit/s
Dec 16 15:18:47.63: [ 1156]: REMOTE wants page width 1728 pixels in
215 mm
Dec 16 15:18:47.64: [ 1156]: REMOTE wants unlimited page length
Dec 16 15:18:47.64: [ 1156]: REMOTE wants 3.85 line/mm
Dec 16 15:18:47.64: [ 1156]: REMOTE wants 2-D MR
Dec 16 15:18:47.64: [ 1156]: <-- [9:AT+FRH=3\r]
Dec 16 15:18:47.64: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:47.75: [ 1156]: --> [10:NO CARRIER]
Dec 16 15:18:47.75: [ 1156]: RECV training at v.17 14400 bit/s
Dec 16 15:18:47.75: [ 1156]: <-- [11:AT+FRM=145\r]
Dec 16 15:18:47.86: [ 1156]: --> [8:+FCERROR]
Dec 16 15:18:47.86: [ 1156]: <-- [11:AT+FRM=145\r]
Dec 16 15:18:49.45: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:50.97: [ 1156]: RECV: TCF 2720 bytes, 0% non-zero, 2699
zero-run
Dec 16 15:18:50.97: [ 1156]: --> [10:NO CARRIER]
Dec 16 15:18:50.97: [ 1156]: DELAY 75 ms
Dec 16 15:18:51.05: [ 1156]: TRAINING succeeded
Dec 16 15:18:51.05: [ 1156]: <-- [9:AT+FTH=3\r]
Dec 16 15:18:51.90: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:51.90: [ 1156]: <-- HDLC<3:FF C8 21>
Dec 16 15:18:51.90: [ 1156]: <-- data [3]
Dec 16 15:18:51.90: [ 1156]: <-- data [2]
Dec 16 15:18:52.23: [ 1156]: --> [2:OK]
Dec 16 15:18:52.23: [ 1156]: MODEM input buffering enabled
Dec 16 15:18:52.23: [ 1156]: <-- [11:AT+FRM=146\r]
Dec 16 15:18:52.87: [ 1156]: --> [8:+FCERROR]
Dec 16 15:18:52.87: [ 1156]: MODEM input buffering disabled
Dec 16 15:18:52.87: [ 1156]: <-- [9:AT+FRH=3\r]
Dec 16 15:18:53.37: [ 1156]: --> [7:CONNECT]
Dec 16 15:18:53.69: [ 1156]: --> [10:NO CARRIER]
Dec 16 15:18:53.69: [ 1156]: MODEM No carrier
Dec 16 15:18:53.69: [ 1156]: MODEM input buffering enabled
Dec 16 15:18:53.69: [ 1156]: <-- [11:AT+FRM=146\r]
Dec 16 15:19:00.41: [ 1156]: --> [8:+FCERROR]
Dec 16 15:19:00.41: [ 1156]: MODEM input buffering disabled
Dec 16 15:19:00.41: [ 1156]: <-- [9:AT+FRH=3\r]
Dec 16 15:19:00.50: [ 1156]: --> [7:CONNECT]
Dec 16 15:19:01.46: [ 1156]: --> HDLC<5:FF C8 F4 CC 66>
Dec 16 15:19:01.46: [ 1156]: --> [2:OK]
Dec 16 15:19:01.46: [ 1156]: RECV recv EOP (no more pages or
documents)
The problem here is that we got the post-page message before any page
was received. According to T.30 the receiver is supposed to send DCN.
So that's what we do...
Dec 16 15:19:01.46: [ 1156]: RECV FAX (000000067):
recvq/fax000000035.tif
from 90 262 6414111, route to <unspecified>, 0 pages in 0:18
Dec 16 15:19:01.46: [ 1156]: RECV FAX: COMREC invalid response
received
Dec 16 15:19:01.46: [ 1156]: <-- [9:AT+FTH=3\r]
Dec 16 15:19:02.32: [ 1156]: --> [7:CONNECT]
Dec 16 15:19:02.32: [ 1156]: <-- HDLC<3:FF C8 5F>
Dec 16 15:19:02.32: [ 1156]: <-- data [3]
Dec 16 15:19:02.32: [ 1156]: <-- data [2]
Dec 16 15:19:02.64: [ 1156]: --> [2:OK]
That's us sending DCN.
I'll be the first to admit that this behavior isn't very friendly. I'm
attaching a patch that you can apply to the SRPM (and then rebuild it -
if you want a pre-built RPM then let me know) that will make our
behavior "more friendly" here by sending RTN (retrain) rather than DCN
(disconnect). It may not help the page reception at all, however. Let
me know how it goes, please.
You may want to first try setting "Class1MsgRecvHackCmd: AT+FRS=1"
(preferred) or "Class1MsgRecvHackCmd: <delay:5>" in your modem config
file (and restarting faxgetty).
Lee.
diff -Nru hylafax-4.2.0.orig/faxd/Class1Recv.c++ hylafax-4.2.0/faxd/Class1Recv.c++
--- hylafax-4.2.0.orig/faxd/Class1Recv.c++ Tue Dec 16 11:06:44 2003
+++ hylafax-4.2.0/faxd/Class1Recv.c++ Wed Dec 17 09:02:21 2003
@@ -578,6 +578,17 @@
case FCF_MPS: // MPS
case FCF_EOM: // EOM
case FCF_EOP: // EOP
+ if (!prevPage) {
+ /*
+ * Post page message, but no previous page
+ * was received. According to T.30 we should
+ * send DCN (as we do below with PRI-PPM),
+ * but to be more friendly, we'll force RTN
+ * instead.
+ */
+ prevPage = true;
+ pageGood = false;
+ }
case FCF_PRI_MPS: // PRI-MPS
case FCF_PRI_EOM: // PRI-EOM
case FCF_PRI_EOP: // PRI-EOP