Re: [hylafax-users] Help debugging modem session log

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

George H wrote:

(from c000024710.txt)
> Jan 14 14:54:15.26: [ 7540]: RECV: 6 total lines, 5 bad lines, 5 
> consecutive bad lines
> Jan 14 14:54:15.26: [ 7540]: RECV: REJECT page quality, 16% good lines 
> (70% required)
> Jan 14 14:54:15.26: [ 7540]: RECV: end page
> Jan 14 14:54:15.40: [ 7540]: --> [256:�-����6^L��M��^N�>�ӴO�����-���Ӹ� 
> 밬㰬�M۰8H��mӲβ۰�۰:l��lúϺۼ, ۼ8o���Ӽ8Ｌ㼬�^N봭˴8-Ӳ ò4���۲:m벭�/�2�먮� 
> <^N˼^L㼮�n뼮�N˼4�ü8,Ӽ>���n˴�$

Here the modem is probably at fault, but it's hard to say what happened, 
exactly. It's a non-ECM fax, and so the image data comes through "raw" 
without any error-correction, and it's very corrupt. Somewhere in all of 
that the modem seems to erroneously pass a DLE+ETX to HylaFAX... and so 
HylaFAX then interprets everything from there until the real carrier 
drop as "garbage"... but it's really image data.

So blame the modem, blame the audio quality. Take your pick. Fix the 
audio quality problem and the modem probably will be fine.

> Jan 15 14:55:45.86: [12165]: RECV received frame number 71
> Jan 15 14:55:46.07: [12165]: RECV received frame number 72
> Jan 15 14:55:46.25: [12165]: RECV assumed RCP frame with block end
> Jan 15 14:55:46.25: [12165]: MODEM set XON/XOFF/DRAIN: input ignored, 
> output disabled
> Jan 15 14:55:46.25: [12165]: MODEM input buffering disabled
> Jan 15 14:55:46.25: [12165]: --> [10:NO CARRIER]
> Jan 15 14:55:46.25: [12165]: <-- [9:AT+FRH=3\r]
> Jan 15 14:56:46.31: [12165]: --> [10:NO CARRIER]

Here the modem detected a premature carrier loss (probably audio jitter) 
and then the AT+FRH=3 then reports yet another non-V.21 HDLC carrier 
loss moments later... however this "NO CARRIER" directly after AT+FRH=3 
currently means to HylaFAX that the call was disconnected... and that's 
a bit inaccurate (especially here). I'm working on a patch to improve 
resiliency here, but the audio is again the catalyst in this fallout.

> Jan 15 18:15:41.01: [ 7540]: RECV received frame number 2
> Jan 15 18:15:41.97: [ 7540]: RECV received frame number 3
> Jan 15 18:15:42.07: [ 7540]: Bad HDLC terminating flag received.
> Jan 15 18:15:42.07: [ 7540]: Bad HDLC terminating flag received.
> Jan 15 18:15:42.21: [ 7540]: RECV assumed RCP frame with block end
> Jan 15 18:15:42.21: [ 7540]: MODEM set XON/XOFF/DRAIN: input ignored, 
> output disabled
> Jan 15 18:15:42.21: [ 7540]: MODEM input buffering disabled
> Jan 15 18:15:42.21: [ 7540]: --> [10:NO CARRIER]
> Jan 15 18:15:42.21: [ 7540]: <-- [9:AT+FRH=3\r]
> Jan 15 18:16:42.69: [ 7540]: --> [10:NO CARRIER]

Same thing here. I wrote up a patch just now to try to address this... 
but I really need to test it first before handing it off to you. It will 
make HylaFAX be more resilient in these NO CARRIER directly after 
AT+FRH=3 situations... although it may not save the session from 
inevitable doom anyway.

Thanks,

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*