HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] Occassional non responsive faxgetty



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




Project hosted by iFAX Solutions