HylaFAX The world's most advanced open source fax server
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] Errors on DeVolo Modem (Microlink)

On 2003.11.28 08:16 Andrea Nicolini wrote:
Hi All,

I'm having troubles in fax reception with a Devolo/Microlink Modem
configured using the Elsa-microlink template.

Is this a different server or did you ditch the ISI modem?

I received the following error which is absolutely new to me.
Do you have any idea on what could it mean?

The bad thing here is that the sender's machine reported
a succesful transmission while it was not!!!

Thank you very much.
Bye.

The full document was not received because:

Procedure interrupt received, job terminated

---- Transcript of session follows ----

Nov 28 15:02:02.01: [ 8621]: SESSION BEGIN 00067104 390434621766
Nov 28 15:02:02.01: [ 8621]: HylaFAX (tm) Version 4.1.7
Nov 28 15:02:02.01: [ 8621]: <-- [4:ATA\r]
Nov 28 15:02:08.02: [ 8621]: --> [74:+FHT: FF 03 40 20 20 20 20 20 36
36 37 31 32 36 20 34 33 34 30 20 39 33 2B]
Nov 28 15:02:08.02: [ 8621]: --> [26:+FHT: FF 13 80 00 6E FA 00]

The first curiosity here is that it takes two DIS cycles before the remote accepts it, +FCO (when we enter Phase B).

Nov 28 15:02:13.30: [ 8621]: --> [74:+FHT: FF 03 40 20 20 20 20 20 36
36 37 31 32 36 20 34 33 34 30 20 39 33 2B]
Nov 28 15:02:13.30: [ 8621]: --> [26:+FHT: FF 13 80 00 6E FA 00]
Nov 28 15:02:16.48: [ 8621]: --> [4:+FCO]
Nov 28 15:02:16.48: [ 8621]: ANSWER: FAX CONNECTION  DEVICE
'/dev/ttyM0'
Nov 28 15:02:16.48: [ 8621]: STATE CHANGE: ANSWERING -> RECEIVING
Nov 28 15:02:16.48: [ 8621]: MODEM input buffering enabled
Nov 28 15:02:16.48: [ 8621]: RECV FAX: begin
Nov 28 15:02:18.01: [ 8621]: --> [74:+FHR: FF 03 43 20 20 20 20 20 20
20 20 20 20 20 20 20 37 34 32 36 38 35 32]
Nov 28 15:02:18.32: [ 8621]: --> [26:+FHR: FF 13 83 00 06 F8 00]
Nov 28 15:02:20.59: [ 8621]: --> [27:+FTI:"1234567             "]
Nov 28 15:02:20.59: [ 8621]: REMOTE TSI "1234567"
Nov 28 15:02:20.59: [ 8621]: --> [20:+FCS:0,3,0,2,0,0,0,0]
Nov 28 15:02:20.59: [ 8621]: REMOTE wants 9600 bit/s
Nov 28 15:02:20.59: [ 8621]: REMOTE wants page width 1728 pixels in
215 mm
Nov 28 15:02:20.59: [ 8621]: REMOTE wants unlimited page length
Nov 28 15:02:20.59: [ 8621]: REMOTE wants 3.85 line/mm
Nov 28 15:02:20.59: [ 8621]: REMOTE wants 1-D MR
Nov 28 15:02:20.59: [ 8621]: --> [2:OK]
Nov 28 15:02:20.59: [ 8621]: <-- [7:AT+FDR\r]
Nov 28 15:02:20.73: [ 8621]: --> [14:+FHT: FF 13 84]
Nov 28 15:02:22.79: [ 8621]: --> [7:CONNECT]
Nov 28 15:02:22.79: [ 8621]: RECV: begin page
Nov 28 15:02:22.79: [ 8621]: RECV: send trigger 022
Nov 28 15:02:45.19: [ 8621]: RECV/CQ: Bad 1D pixel count, row 1208,
got 0, expected 1728
Nov 28 15:02:45.19: [ 8621]: RECV/CQ: Bad 1D pixel count, row 1209,
got 0, expected 1728
Nov 28 15:02:45.19: [ 8621]: RECV/CQ: Bad 1D pixel count, row 1210,
got 0, expected 1728
Nov 28 15:02:45.19: [ 8621]: RECV/CQ: Bad 1D pixel count, row 1211,
got 0, expected 1728
Nov 28 15:02:45.19: [ 8621]: RECV/CQ: Bad 1D pixel count, row 1212,
got 0, expected 1728
Nov 28 15:02:45.19: [ 8621]: RECV: 23047 bytes of data, 1213 total
lines
Nov 28 15:02:45.62: [ 8621]: --> [16:+FPS:1,4BE,0,0,0]

The modem counted 1214 lines, by the way. So there seems to be some discrepancy between what the DCE is relaying to the DTE and what the DCE is receiving from the remote DCE. It's possible that the DCE is just counting EOLs rather than counting lines of image data, and the RTC is causing it to add some "blank" lines at the bottom. Anyway, not a real problem, just a curiosity.

Nov 28 15:02:47.07: [ 8621]: --> [14:+FHR: FF 13 3F]
Nov 28 15:02:47.07: [ 8621]: --> [6:+FET:6]
Nov 28 15:02:47.07: [ 8621]: RECV recv PRI-EOP (no more pages after
interrupt)

Although the "3F" (actually "FC") signal here indicates PRI-EOP. I've never seen PRI used by a sender. It's possible that PRI-EOP was misinterpreted by the DCE because it didn't check the CRC. Anyway, PRI-EOP indicates that it's the last page of the documents to be sent, but if a human pushes the "continue" button on the fax machine we should start again at phase B (an ugly way to send multiple documents). PRI is not for use with automated systems.

Nov 28 15:02:47.07: [ 8621]: --> [2:OK]
Nov 28 15:02:47.07: [ 8621]: RECV send MCF (message confirmation)

This is correct. We did get the message properly. But, as you mention, I don't see an +FHT: report showing this signal transmission, so I really don't know how the remote got "confirmation".

Nov 28 15:02:47.07: [ 8621]: RECV FAX (00067104): from 123456, page 1
in 0:27, INF, 3.85 line/mm, 1-D MR, 9600 bit/s
Nov 28 15:02:47.07: [ 8621]: RECV FAX (00067104): recvq/fax33967.tif
from 1234567, route to <unspecified>, 1 pages in 0:31
Nov 28 15:02:47.07: [ 8621]: RECV FAX: Procedure interrupt received,
job terminated
Nov 28 15:02:47.07: [ 8621]: <-- [7:AT+FKS\r]
Nov 28 15:02:47.21: [ 8621]: --> [14:+FHT: FF 13 FA]

This is us sending DCN.

Nov 28 15:02:48.55: [ 8621]: --> [7:+FHS:02]
Nov 28 15:02:48.55: [ 8621]: REMOTE HANGUP: Call aborted,  from +FK or
<CAN> (code 2)
Nov 28 15:02:48.55: [ 8621]: --> [2:OK]
Nov 28 15:02:48.55: [ 8621]: RECV FAX (00067104): session with 1234567
terminated abnormally: Procedure interrupt received, job terminated
Nov 28 15:02:48.55: [ 8621]: RECV FAX: bin/faxrcvd
"recvq/fax33967.tif" "ttyM0" "00067104" "Procedure interrupt received,
job terminated" "" ""

First off, we *did* actually receive the data properly. SaveUnconfirmedPages in HylaFAX CVS HEAD (to-be 4.2.0) would at least keep that data from being deleted by the server. However, we did not send confirmation of the receipt, as far as the modem reports.

Is it possible that this modem is actually performing ECM "behind the scenes"? Only then can I imagine how this occurred (MCF was sent during ECM protocol, which is hidden from the DTE, and so the DCE has already sent MCF by the time it tells us PPM and then ignores our subsequent MCF).

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*

Project hosted by iFAX Solutions