Re: [hylafax-users] Possible Class2 RCV Bug and Proposed Fix

[Lee Howard <faxguy@howardsilvan.com>]

On 2002.12.30 05:51 cbain wrote:

> My proposed changes are:
> 
> In faxd/Class2.c++,
> 
> Change error message for unexpect hangup;
> 
> static struct HangupCode {
>     const char*	code[3];	// from 2388/89, 2388/90,
> 2388-A, and 2388-B
>     const char*	message;	// what code means
> } hangupCodes[] = {
> // Call placement and termination
> // - old message
> //    {{  "0",  "0",  "0" }, "Normal and proper end of connection" },
> // - new message and +FHNG when unexpected is an error
>     {{  "0",  "0",  "0" }, "Unexpected end of connection" },

This is not good because this would cause fax sessions which ended 
properly to have "Unexpected end of connection" in the log.  The cold 
fact is that +FHNG:0/+FHS:0 literally means "Normal and proper end of 
connection" (see T.32).  We can't change this.  The fact that the 
modem's firmware reports +FHNG:0 when it shouldn't is an issue that 
would need to be taken up with the modem manufacturer.  Obviously the 
modem has some kind of problem in post-page (possibly copy quality 
checking) handling.

> Also In faxd/Class2.c++,
> 
> Change waitFor() to return error on unexpected +FHNG from modem:
> 
> bool
> Class2Modem::waitFor(ATResponse wanted, long ms)
> {
>     for (;;) {
> 	ATResponse response = atResponse(rbuf, ms);
> 	if (response == wanted)
> 	    return (true);
> 	switch (response) {
> 	case AT_TIMEOUT:
> 	case AT_EMPTYLINE:
> 	case AT_ERROR:
> 	case AT_NOCARRIER:
> 	case AT_NODIALTONE:
> 	case AT_NOANSWER:
> 	case AT_RING:
> 	    modemTrace("MODEM %s", ATresponses[response]);
> 	    return (false);
> 	case AT_FHNG:
> 	    // return hangup status, but try to wait for requested
> response
> 	    { char buf[1024]; (void) atResponse(buf, 2*1000); }
> 	    return(false);		// a hang-up when not
> expected is always an error
> // old code returned true if +FHNG did not give error status
> //	    return (isNormalHangup());
> 	}
>     }
> }

I'd tend to side with you on this one, although I'd prefer to just do 
something more simple which would save us 2 seconds:

bool
Class2Modem::waitFor(ATResponse wanted, long ms)
{
     for (;;) {
	ATResponse response = atResponse(rbuf, ms);
	if (response == wanted)
	    return (true);
	switch (response) {
	case AT_TIMEOUT:
	case AT_EMPTYLINE:
	case AT_ERROR:
	case AT_NOCARRIER:
	case AT_NODIALTONE:
	case AT_NOANSWER:
	case AT_RING:
	case AT_FHNG:
	    modemTrace("MODEM %s", ATresponses[response]);
	    return (false);
	}
     }
}

> Here is the class 2 modem receive log that caused the discovery:
....
> Dec 19 18:01:11.49: [  279]: <-- data [1]
> Dec 19 18:01:11.82: [  279]: RECV: 0 total lines, 0 bad lines, 0
> consecutive bad lines
> Dec 19 18:01:11.82: [  279]: --> [17:+FPTS: 2,2219,0,0]
> Dec 19 18:01:13.15: [  279]: --> [8:+FHNG: 0]
> Dec 19 18:01:13.15: [  279]: REMOTE HANGUP: Normal and proper end of
> connection (code 0)
> Dec 19 18:01:14.60: [  279]: --> [2:OK]
> Dec 19 18:01:14.60: [  279]: RECV recv MPS (more pages, same document)
> Dec 19 18:01:44.60: [  279]: MODEM <Timeout>

I'd like to see a log of this situation occurring *after* your changes 
before committing anything to CVS.

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@hylafax.org < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*