Re: [hylafax-users] Occassional non responsive faxgetty

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.09.03 15:10 John Edmondson wrote:

> Sep 01 15:04:24.20: [ 1187]: RECV recv MPS (more pages, same document)
> Sep 01 15:04:24.20: [ 1187]: <-- [9:AT+FRS=7\r]
> Sep 01 15:04:24.41: [ 1187]: --> [2:OK]
> Sep 01 15:04:24.41: [ 1187]: <-- [9:AT+FTH=3\r]
> Sep 01 15:04:54.41: [ 1187]: MODEM <Timeout>
> Sep 01 15:04:54.41: [ 1187]: RECV send MCF (message confirmation)
> Sep 01 15:04:54.41: [ 1187]: RECV FAX (000007068): from 999 999 9999, 
> page 1 in 1:15, INF, 7.7 line/mm, 1-D MH, 14400 bit/s
> Sep 01 15:04:54.41: [ 1187]: <-- data [3]
> Sep 01 15:04:54.41: [ 1187]: <-- data [2]
> Sep 01 16:28:39.60: [ 1187]: CLOSE /dev/ttyS0

You could try the attached patch.

It will cause the session to fail when the AT+FTH=3 fails rather than 
trying to continue.  (Which, I believe is the right thing to do.)

I'm not sure why the timeout on sendFrame() isn't working.  It's 
supposed to.  See the bug reports:

http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=543
http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=472

Which should describe the relevant changes that occurred between 4.1.6 
and 4.2.0 that are giving you grief.

But, you won't have the need for the sendFrame() timeout if the 
attached patch is used and the error only occurs when trying to send 
MCF at the end of a page.

The modem problem causing this is a familiar USR bug.  Some people have 
managed to avoid that bug by changing their modem configs from using 
AT+FRS=n/AT+FTS=n.  Look at config/topic for how this is done.

Lee.

Attachment: foo
Description: Binary data