Re: [hylafax-users] "Successful" Faxes never receied after delay in 4.1.8

[Bill Binko <bill-sender-4b2fd6@xxxxxxxxx>]

Lee,

  Thanks for the response.  If you were responding to get forwarded to my
client (and I think you were), it worked.  I'll be forwarding that and
arguing hard to move to 4.2.0 this weekend.

  As for the new firmware, I thought the last official word from Steve was
a recall of some improperly released firmware?  I may be mistaken: I
backed out of one version, and I know he was near release of another. I
will double check.

Thanks for the quick response.

Bill

 On Tue, 27 Jul 2004, Lee Howard wrote:

> On 2004.07.27 15:28 Bill Binko wrote:
> > Hello everyone,
> >
> > We have been seeing faxes sent to several destinations that were
> > declared
> > "successful" by hylafax never actually print on the far end.  I've
> > looked
> > at the comm logs, and have noticed that all of them have a delay
> > between
> > when hylafax sends EOP (no more pages) and when the remote responds
> > with
> > +FHS:0 and hylafax says "Normal and proper end of connection".
> >
> > The delay seems to be between 20 and 60 seconds.  Here is a sample:
> >
> > Jul 27 16:43:10.91: [16402]: <-- data [1027]
> > Jul 27 16:43:11.10: [16402]: <-- data [364]
> > Jul 27 16:43:11.10: [16402]: SENT 22890 bytes of data
> > Jul 27 16:43:11.10: [16402]: SEND 2D RTC
> > Jul 27 16:43:11.10: [16402]: <-- data [10]
> > Jul 27 16:43:11.28: [16402]: SEND end page
> > Jul 27 16:43:11.28: [16402]: SEND send EOP (no more pages or
> > documents)
> > Jul 27 16:43:11.28: [16402]: <-- data [2]
> > Jul 27 16:43:55.50: [16402]: --> [6:+FHS:0]
> > Jul 27 16:43:55.50: [16402]: REMOTE HANGUP: Normal and proper end of
> > connection (code 0)
> > Jul 27 16:43:55.50: [16402]: SEND recv MCF (message confirmation)
> > ... email omitted
> > Jul 27 16:43:55.50: [16402]: <-- [5:ATH0\r]
> > Jul 27 16:43:55.50: [16402]: --> [2:OK]
> > Jul 27 16:43:55.50: [16402]: SESSION END
> >
> > Notice the delay btween 16:43:11 and 16:43:55.
>
> Nothing really can be concluded from that delay.  If using ECM the
> modem in Class 2.1 will spend a lot of time sometimes, trying to push a
> single page through (especially if the connection speed must be slowed
> down a few times).  Obviously there is a misunderstanding, however,
> between the sender and the receiver with regards to the post-page
> status, however.  This is something that only MultiTech is going to be
> able to fix for you.  You'd probably be much better served with 4.2.0
> in Class 1.0.
>
> > We are running Hylafax 4.1.8 on Mandrake 10.0
> > (hylafax-server-4.1.8-2mdk)
> > using three internal Multitech ZPX modems.
> >
> > The modem IDs as : MODEM MULTI-TECH SYSTEMS MT5634ZPX-PCI-V92/1.25p
>
> I'm not certain of this, but I think that your firmware can be
> updated.  I think that 1.32 is the new version number.
>
> > We are running in class 2.1 with certain features disabled due to
> > firmware
> > issues.
>
> These may be fixed in the new firmware, and they aren't relevant in
> Class 1/1.0.
>
> > I have been trying (unsuccessfully) to convince my client to go to
> > 4.2.0rc2 and class 1.0.  I realize that that would probably solve most
> > of
> > my problems including this one.  I can't get him to go to class 1 with
> > 4.1.8 due to the amount of v.34 (38.4) faxing he does.
>
> Which is why he should go to 4.2.0 Class 1.0.
>
> > Is this a known issue, and is it fixed in 4.2.0?
>
> The issue, if there is one, is a MultiTech matter.  It is nothing that
> can be fixed in any HylaFAX release.  In this case the modem is telling
> HylaFAX that the fax went just fine.  How can HylaFAX argue about
> that?  The only thing to do at that point is to fix the modem or to
> take the responsibility for handling the fax protocol from the modem
> (by switching to Class 1/1.0).  The "issue" is irrelevant to Class
> 1/1.0 function.
>
> > If so, it would be a
> > great motivator for me to use to get my client to move.  Their big
> > issue
> > is the "rc" status.
>
> "Status" isn't really the right terminology for it.  It's just a label
> that means "okay, we're going to make this a release unless someone
> discovers a major issue with it before long".  The only real thing that
> it indicates is that it hasn't had as much exposure as the previous
> full release.  Perhaps in other packages the CVS/beta/rc releases are a
> mess full of experimental things, but not with HylaFAX.  A full release
> doesn't really mean that there are no known bugs in it; it certainly
> doesn't guarantee flawless performance.  As with any software, you try
> it, and it should work for you as expected.  If it doesn't, then you
> revert back to the way it was or you fix the way that it is.
>
> I think that if you could survey this you would find that many, many
> production servers have been running what has become 4.2.0 for a long,
> long time.  Realize that the 4.2 code branch split from 4.1 back just
> after 4.1.6 - a little over a year ago.  So anyone who has wanted the
> features (extended resolutions, ECM, MMR, V.34, integrated line IDs,
> returned fax documents via e-mail attachment, etc.) or any of the
> myriad of bugfixes therein has needed to run "CVS" or "beta" or "rc"
> code for a while now.
>
> > I've explained that it shouldn't be an issue
> > (open
> > source, it being more stable than 4.1.8, etc).  So far, they want to
> > wait.
>
> I am intimately aware of all of the flaws and shortcomings that have
> been fixed in 4.1.8 to produce 4.2.0, and there is no way I would ever
> choose to use it in lieu of 4.2.0 on my clients' systems.  If they were
> afraid of the new features... well, then the one with largest impact
> can be disabled with this:
>
> Class1ECMSupport: no
>
> Note, however, that in doing so you deprive yourself of what has to be
> the greatest extension to T.30 since sliced bread.
>
> 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*
>
>


____________________ 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*