Re: [hylafax-users] Errors: HDLC frame not byte-oriented, Bad HDLC terminating flag received.

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.02.28 22:12 Alexander Slepoy wrote:
> I have 2 many errors (1 of 10 incoming faxes),  on:
> Hylafax CVS HEAD with ECM
> Modem Rockwell Based Class 1 modem
> What can I try to do?
> Regards,
> Alexander Slepoy

> Feb 26 13:34:02.85: [28953]: RECV received frame number 7
> Feb 26 13:34:02.99: [28953]: RECV received frame number 8
> Feb 26 13:34:03.14: [28953]: HDLC frame not byte-oriented.  Trailing
> byte:
> 0xf0

This means that the last set of data was known to be bad because the 
trailing byte, 0xF0, was not a proper sync flag (0x7E) - it means 
essentially the same thing as "FCS check failed".  That frame of data 
was bad.

> Feb 26 13:34:03.62: [28953]: RECV assumed RCP frame with block end

This means that the block ended (either due to <DLE><ETX> or "NO 
CARRIER") unexpectedly before any RCP frames were received.

> Feb 26 13:34:03.62: [28953]: --> [10:NO CARRIER]

This means that the cause of all of the problems above were the result 
of an unexpected carrier drop.

> Feb 26 13:34:03.62: [28953]: <-- [9:AT+FRH=3\r]
> Feb 26 13:34:09.64: [28953]: --> [7:CONNECT]
> Feb 26 13:34:10.61: [28953]: --> [2:OK]
> Feb 26 13:34:10.61: [28953]: RECV recv PPS (partial page signal)
> Feb 26 13:34:10.61: [28953]: RECV recv EOP (no more pages or
> documents)

So the remote is still there... that's good news.

> Feb 26 13:34:10.61: [28953]: RECV received 52 frames of block 1 of
> page 1
> Feb 26 13:34:10.61: [28953]: <-- [9:AT+FRS=7\r]
> Feb 26 13:34:10.74: [28953]: --> [2:OK]
> Feb 26 13:34:10.74: [28953]: <-- [9:AT+FTH=3\r]
> Feb 26 13:34:10.79: [28953]: --> [7:CONNECT]
> Feb 26 13:34:13.12: [28953]: --> [2:OK]
> Feb 26 13:34:13.12: [28953]: RECV send PPR (partial page request)
> Feb 26 13:34:13.12: [28953]: <-- [11:AT+FRM=146\r]
> Feb 26 13:34:17.09: [28953]: --> [8:+FCERROR]

This tells us that the connection is still there but we're not properly 
hearing the expected carrier.

> Feb 26 13:34:17.09: [28953]: <-- [11:AT+FRM=146\r]
> Feb 26 13:34:24.09: [28953]: RECV keeping unconfirmed page

Well... now that we can't find the remote... we give up.

See:
http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=511
for a possible way to recover from these problems.  It doesn't prevent 
the problem from happening, but it may help recover from it.

> Feb 27 10:19:19.38: [28953]: RECV received frame number 31
> Feb 27 10:19:19.80: [28953]: RECV received frame number 32
> Feb 27 10:19:19.80: [28953]: Bad HDLC terminating flag received.
> Feb 27 10:19:19.80: [28953]: RECV assumed RCP frame with block end
> Feb 27 10:19:19.80: [28953]: --> [10:NO CARRIER]

Again, same thing as before.

> Feb 27 10:19:19.80: [28953]: <-- [9:AT+FRH=3\r]
> Feb 27 10:19:26.80: [28953]: --> [0:]
> Feb 27 10:19:26.80: [28953]: MODEM <Empty line>
> Feb 27 10:19:26.86: [28953]: --> [2:OK]

This tells us that the remote, if it's still there, is still sending 
image data.  Somehow we got a carrier drop prematurely.

I'd recommend trying a different modem and/or checking your lines.  
Something is causing the modem to hear a carrier drop when it really 
doesn't happen.  You may want to check your modem manual for an 
S-register setting that deals with this kind of sensitivity.

For testing purposes (just to show that the problem isn't an 
ECM-related matter), you could set "Class1ECMSupport: no" in your modem 
config file.  You should still see the same kinds of problems.

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*