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] Receive error



On 2004.05.10 04:46 Jörg Wiesenfeller wrote:
Hello all,

we have a hylafax-server (CVS) running on SuSe 8.1. We use 2 GVC 288
modem
for receiving and an AVM Isdn card for sending faxes.
While sending works very well, we have some problems with receiving
faxes.
About 10-20 times a day we got following error.

Failed to properly detect high-speed data carrier.

This means that HylaFAX (faxgetty) was unable to raise the high-speed data carrier. The carriers are raised and dropped a lot with ECM.


Any clues on this ?

Here you are going fine, and then all of the sudden the data becomes garbled...


May 10 12:58:17.56: [ 3657]: RECV received frame number 72
May 10 12:58:17.72: [ 3657]: RECV received frame number 73
May 10 12:58:17.87: [ 3657]: RECV received frame number 74
May 10 12:58:18.02: [ 3657]: RECV received frame number 75
May 10 12:58:18.09: [ 3657]: HDLC frame not byte-oriented.  Trailing
byte:
0xc0
...
May 10 12:58:29.05: [ 3657]: HDLC frame too short (2 bytes)
May 10 12:58:29.20: [ 3657]: HDLC frame not byte-oriented.  Trailing
byte:
0xc0
May 10 12:58:29.20: [ 3657]: HDLC frame not byte-oriented.  Trailing
byte:
0xfc
May 10 12:58:29.20: [ 3657]: HDLC frame not byte-oriented.  Trailing
byte: 0
May 10 12:58:29.33: [ 3657]: RECV assumed RCP frame with block end
May 10 12:58:29.33: [ 3657]: --> [10:NO CARRIER]

... it's so garbled that the RCP frames are missed, but the carrier drop is detected. You're going to have to respond with PPR, re-raise the reception carrier, and reattempt reception of the frames that you missed.


May 10 12:58:29.33: [ 3657]: <-- [9:AT+FRH=3\r]
May 10 12:58:29.53: [ 3657]: --> [7:CONNECT]
May 10 12:58:30.61: [ 3657]: --> [2:OK]
May 10 12:58:30.61: [ 3657]: RECV recv PPS (partial page signal)
May 10 12:58:30.61: [ 3657]: RECV recv MPS (more pages, same document)
May 10 12:58:30.61: [ 3657]: RECV received 152 frames of block 1 of
page 2

So you only got about half the page properly. The low-speed carrier seems to be unaffected by whatever happened.


May 10 12:58:30.61: [ 3657]: <-- [9:AT+FRS=7\r]
May 10 12:58:30.70: [ 3657]: --> [2:OK]
May 10 12:58:30.70: [ 3657]: <-- [9:AT+FTH=3\r]
May 10 12:58:30.72: [ 3657]: --> [7:CONNECT]
May 10 12:58:32.84: [ 3657]: --> [2:OK]
May 10 12:58:32.84: [ 3657]: RECV send PPR (partial page request)
May 10 12:58:32.84: [ 3657]: <-- [11:AT+FRM=146\r]
May 10 12:58:32.96: [ 3657]: --> [5:ERROR]

And, here's the problem. What does ERROR mean? The spec doesn't say that ERROR is a valid response, and normally I'd guess that it means that the modem is on-hook. We know that's not the case, though, because the next command (sending DCN) doesn't result in ERROR.


There is a note in the Class 1 code (put there by a trustworthy developer) that some modems respond to +FRM with ERROR instead of +FCERROR when it encounters the wrong carrier, but doesn't return to command mode. When this happens in non-ECM faxing the session is aborted. In your ECM case, though, it looks like it did return to command mode.

So, I guess the questions are: what does ERROR mean here, and what should we do to recover? Can you possibly get these answers from the modem documentation or from GVC support?

Assuming that, in this case, ERROR == +FCERROR, I can write you a code patch to test this hypothesis. Do you want this?

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@xxxxxxxxx*




Project hosted by iFAX Solutions