Re: [hylafax-users] some error logs

[Lee Howard <faxguy@deanox.com>]

>> Sep 19 00:47:19.30: [  701]: --> [15:+FPS:1,15,0,0,0]
>
>Looks like the USR's firmware bug. According to Class2/2.0 specs +FET
>should be present, but it does not. Not having +FET after +FPS Hylafax
>gives up here.
>
>> Sep 19 00:47:23.40: [  701]: --> [5:ERROR]
>> Sep 19 00:47:23.40: [  701]: MODEM Command error
>
>If +FET had been found, Hylafax would have interpreted this ERROR as RTN
>signal. But now it just prints the default error message.

Yet, this lack of +FET is inconsistent.  Here it is just now *with* +FET:
(I apologize if the following is redundant.  I'm just trying to be thorough.)

Sep 19 15:14:14.67: [11953]: RECV/CQ: Adjusting for RTC found at row 1094
Sep 19 15:14:14.67: [11953]: RECV: 1094 total lines, 0 bad lines, 0
consecutive$
Sep 19 15:14:14.67: [11953]: --> [17:+FPS:1,1099,0,0,0]
Sep 19 15:14:16.03: [11953]: --> [6:+FET:2]
Sep 19 15:14:16.03: [11953]: RECV recv EOP (no more pages or documents)
Sep 19 15:14:16.03: [11953]: --> [2:OK]
Sep 19 15:14:16.03: [11953]: RECV send MCF (message confirmation)

and again...
Sep 19 14:10:27.41: [  701]: RECV/CQ: Adjusting for RTC found at row 1075
Sep 19 14:10:27.41: [  701]: RECV: 1075 total lines, 0 bad lines, 0
consecutive$
Sep 19 14:10:27.41: [  701]: --> [17:+FPS:1,1081,0,0,0]
Sep 19 14:10:28.66: [  701]: --> [6:+FET:0]
Sep 19 14:10:28.66: [  701]: RECV recv MPS (more pages, same document)
Sep 19 14:10:28.66: [  701]: --> [2:OK]
Sep 19 14:10:28.66: [  701]: RECV send MCF (message confirmation)

and again...
Sep 19 11:36:08.39: [  701]: RECV/CQ: Adjusting for RTC found at row 1091
Sep 19 11:36:08.39: [  701]: RECV: 1091 total lines, 0 bad lines, 0
consecutive$
Sep 19 11:36:08.39: [  701]: --> [17:+FPS:1,1096,0,0,0]
Sep 19 11:36:09.64: [  701]: --> [6:+FET:2]
Sep 19 11:36:09.64: [  701]: RECV recv EOP (no more pages or documents)
Sep 19 11:36:09.64: [  701]: --> [2:OK]
Sep 19 11:36:09.64: [  701]: RECV send MCF (message confirmation)

and again...
Sep 19 07:45:13.69: [  701]: RECV/CQ: Adjusting for trailing noise (6 run)
Sep 19 07:45:13.69: [  701]: RECV: 1076 total lines, 0 bad lines, 0
consecutive$
Sep 19 07:45:13.69: [  701]: --> [17:+FPS:1,1079,0,0,0]
Sep 19 07:45:14.92: [  701]: --> [6:+FET:2]
Sep 19 07:45:14.92: [  701]: RECV recv EOP (no more pages or documents)
Sep 19 07:45:14.92: [  701]: --> [2:OK]
Sep 19 07:45:14.92: [  701]: RECV send MCF (message confirmation)

and again...
Sep 19 04:10:24.35: [  701]: RECV/CQ: Adjusting for RTC found at row 2199
Sep 19 04:10:24.35: [  701]: RECV: 2199 total lines, 0 bad lines, 0
consecutive$
Sep 19 04:10:24.35: [  701]: --> [17:+FPS:1,2203,0,0,0]
Sep 19 04:10:25.58: [  701]: --> [6:+FET:2]
Sep 19 04:10:25.58: [  701]: RECV recv EOP (no more pages or documents)
Sep 19 04:10:25.58: [  701]: --> [2:OK]
Sep 19 04:10:25.58: [  701]: RECV send MCF (message confirmation)

Those aren't all of the good logs, obviously.  I only get an error about
once every two days.  Here are all of the errors in my log cache (note that
I only turned 'SessionTracing: 0xFFF' yesterday, so most of these error
logs are limited):

Aug 24 23:20:52.06: [  659]: RECV: 623 total lines, 14 bad lines, 2
consecutive
bad lines
Aug 24 23:20:52.17: [  659]: --> [16:+FPS:1,625,0,0,0]
Aug 24 23:20:55.12: [  659]: --> [5:ERROR]
Aug 24 23:20:55.12: [  659]: MODEM Command error

Aug 29 13:32:38.10: [  659]: RECV: 589 total lines, 77 bad lines, 4
consecutive
bad lines
Aug 29 13:32:38.11: [  659]: --> [16:+FPS:1,590,0,0,0]
Aug 29 13:32:42.78: [  659]: --> [5:ERROR]
Aug 29 13:32:42.78: [  659]: MODEM Command error

Aug 30 14:20:33.13: [  659]: RECV: 1 total lines, 0 bad lines, 0
consecutive bad
 lines
Aug 30 14:20:33.13: [  659]: --> [14:+FPS:1,3,0,0,0]
Aug 30 14:20:38.56: [  659]: --> [5:ERROR]
Aug 30 14:20:38.56: [  659]: MODEM Command error

Sep 08 14:19:21.57: [  701]: RECV: 1026 total lines, 43 bad lines, 4
consecutive
 bad lines
Sep 08 14:19:21.58: [  701]: --> [17:+FPS:1,1030,0,0,0]
Sep 08 14:19:25.52: [  701]: --> [5:ERROR]
Sep 08 14:19:25.52: [  701]: MODEM Command error

Sep 15 12:37:49.48: [  701]: RECV: 951 total lines, 105 bad lines, 4
consecutive
 bad lines
Sep 15 12:37:49.48: [  701]: --> [16:+FPS:1,957,0,0,0]
Sep 15 12:37:53.42: [  701]: --> [5:ERROR]
Sep 15 12:37:53.42: [  701]: MODEM Command error

Sep 17 09:04:06.64: [  701]: RECV: 26 total lines, 0 bad lines, 0
consecutive ba
d lines
Sep 17 09:04:06.64: [  701]: --> [15:+FPS:1,27,0,0,0]
Sep 17 09:04:11.60: [  701]: --> [5:ERROR]
Sep 17 09:04:11.60: [  701]: MODEM Command error

Sep 19 00:47:19.30: [  701]: RECV: 12 total lines, 0 bad lines, 0
consecutive ba
d lines
Sep 19 00:47:19.30: [  701]: --> [15:+FPS:1,15,0,0,0]
Sep 19 00:47:23.40: [  701]: --> [5:ERROR]
Sep 19 00:47:23.40: [  701]: MODEM Command error

Anyway, I know this is long, but my point is this... I see a pattern here,
in that *all* of the +FPS:a,b,c,d,e sequences have *low* (and most are
*very* low) values for b when the +FET fails.  The average in all my log
cache for b is 1776 (it's patriotic apparently), but all of them are less
than 1031, and none of them are even close to the average value.  What does
that b value indicate anyway?

This only happens on receiving.

There are about equal number of successful faxes as failed faxes, though,
that are also received with low 'b' values in the +FPS string, but *none*
of these failed faxes have high or average values for 'b'.

Is this coincidence or is this evidence of an inconsistent bug in HylaFAX
or the USR firmware?

>Are you still sure that USR's Class2 is excellent? :-)

Oh, I was mostly just teasing you Dmitry about the USR firmware ;-)  Sure,
I'll agree that USR really made a mess of this (and other fax things).  But
my frustration lies in the fact that there are *so* many USR modems out
there - most of my customers already have one and want to use it.  Jay
insists on selling people new Multitech modems, and I agree with him, but
most of my customers would rather put up with an occasional problem rather
than paying $100 for a new modem on-top of my services.  (Yep, we're all a
bunch of cheap hicks out here ;-)

You could really make my day, Dmitry, if you told me that this was a
HylaFAX bug and these logs just helped you find it.  But, if it is a USR
firmware bug that is causing this, is it possible to create some code that
can "work around" this bug and prevent these errors from happening by
sending +FET *for* the modem when it doesn't do it independently?

Maybe I don't know what I'm talking about?

Thanks.

Lee.

>Hope to hear from you soon,
>Dmitry
>



____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null