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] seeing problems on panasonic faxmachine




On Sep 7, 2005, at 11:18 PM, Lee Howard wrote:


offman wrote:


Sep 07 10:01:38.04: [17117]: SEND recv PPR (partial page request)
Sep 07 10:01:38.04: [17117]: <-- [9:AT+FRS=7\r]
Sep 07 10:01:38.16: [17117]: --> [2:OK]
Sep 07 10:01:38.16: [17117]: DELAY 200 ms
Sep 07 10:01:38.36: [17117]: <-- [11:AT+FTM=122\r]
Sep 07 10:01:38.40: [17117]: --> [7:CONNECT]
Sep 07 10:01:38.98: [17117]: --> [2:OK]



From this we can tell that the receiver sent us an empty PPR signal... meaning that the PPR signal indicated that all of the frames that we transmitted were received correctly. So the receiver should have sent MCF and not PPR; however, something that happened (perhaps the duplicate sending of the single-frame 25 in one block) has confused the receiver and makes it think that there are still frames that it needs to get before sending MCF.

So at this point our only choice is to send empty blocks until the 4th PPR signal is received and then to send EOR (to end retransmissions and move on).

I continue below...


Sep 07 10:01:38.98: [17117]: <-- [9:AT+FTS=9\r]
Sep 07 10:01:39.08: [17117]: --> [2:OK]
Sep 07 10:01:39.08: [17117]: <-- [9:AT+FTH=3\r]
Sep 07 10:01:39.13: [17117]: --> [7:CONNECT]
Sep 07 10:01:40.55: [17117]: --> [2:OK]
Sep 07 10:01:40.55: [17117]: SEND send PPS (partial page signal)
Sep 07 10:01:40.55: [17117]: SEND send EOM (more documents)
Sep 07 10:01:40.55: [17117]: <-- [9:AT+FRH=3\r]
Sep 07 10:01:41.31: [17117]: --> [7:CONNECT]
Sep 07 10:01:43.12: [17117]: --> [2:OK]
Sep 07 10:01:43.12: [17117]: SEND recv PPR (partial page request)
Sep 07 10:01:43.12: [17117]: <-- [9:AT+FRS=7\r]
Sep 07 10:01:43.24: [17117]: --> [2:OK]
Sep 07 10:01:43.24: [17117]: <-- [9:AT+FTH=3\r]
Sep 07 10:01:43.29: [17117]: --> [7:CONNECT]
Sep 07 10:01:44.63: [17117]: --> [2:OK]
Sep 07 10:01:44.63: [17117]: SEND send EOR (end of retransmission)
Sep 07 10:01:44.63: [17117]: SEND send EOM (more documents)
Sep 07 10:01:44.63: [17117]: <-- [9:AT+FRH=3\r]
Sep 07 10:01:45.39: [17117]: --> [7:CONNECT]
Sep 07 10:01:46.32: [17117]: --> [2:OK]
Sep 07 10:01:46.32: [17117]: SEND recv ERR (confirm end of retransmission)




According to T.30 the ERR signal is a confirmation to EOR and indicates that the receiver is ready to continue without requiring any further retransmissions of the previous block. However, many fax machines out there (and apparently this Panasonic) will abort either after receiving EOR or after sending ERR. They do this with reason (good reason, from their point of view), and so for the most part the best thing that can be done is to do all that we can to avoid EOR.

I continue below...


Sep 07 10:01:46.32: [17117]: SEND end page
Sep 07 10:01:46.33: [17117]: SEND FAX (000000485): FROM steve@xxxxxxxxxxxxxxxx,sluo@xxxxxxxxxxxxxxxx TO 0-17909-00-852---26669677 (page 1 of 1 sent in 1:03)
Sep 07 10:01:46.33: [17117]: SEND FAX (000000485): FROM steve@xxxxxxxxxxxxxxxx,sluo@xxxxxxxxxxxxxxxx TO 0-17909-00-852---26669677 (docq/doc200.ps;c1 sent in 1:03)
Sep 07 10:01:47.35: [17117]: SEND FAX: JOB 202 DEST 0-17909-00-852---26669677 COMMID 000000485 DEVICE '/dev/ttyS1'
Sep 07 10:01:47.35: [17117]: <-- [9:AT+FRH=3\r]
Sep 07 10:01:47.36: [17117]: --> [7:CONNECT]
Sep 07 10:01:47.37: [17117]: --> [5:ERROR]
Sep 07 10:01:47.37: [17117]: MODEM Command error
Sep 07 10:01:47.37: [17117]: FCS error
Sep 07 10:01:47.37: [17117]: <-- [9:AT+FRS=7\r]
Sep 07 10:01:47.48: [17117]: --> [2:OK]
Sep 07 10:01:47.48: [17117]: <-- [9:AT+FTH=3\r]
Sep 07 10:01:47.53: [17117]: --> [7:CONNECT]
Sep 07 10:01:48.84: [17117]: --> [2:OK]
Sep 07 10:01:48.84: [17117]: SEND send CRP (command repeat)
Sep 07 10:01:48.84: [17117]: <-- [9:AT+FRH=3\r]
Sep 07 10:01:49.60: [17117]: --> [7:CONNECT]
Sep 07 10:01:50.51: [17117]: --> [2:OK]
Sep 07 10:01:50.51: [17117]: COMREC error in transmit Phase B/got DCN




Yes, see here the receiver triggered an abort.

So what can be done to prevent EOR? Well, the best thing to do is to limit the risk of PPR. Getting PPR means that the data was corrupted somewhere after HylaFAX delivered it to the modem and before the receiver got it. So for the most part that means "line noise", but it could also mean bad modulators on the modem or fax machine, etc. So you review your logs and see if PPR is frequent - even to local fax machines, and if it is, then something's probably wrong with your own telco connection. If not, then you may want to have the receiver check theirs. And if they're also clean, then you'd want to try a different modem to see if that helps.

We could also try to figure out what it is that HylaFAX is doing that triggers this problem (empty PPR) on the receiver. To do that I'd need to be able to send some test faxes to a problematic destination from my development system.

Lee.




this is an odd machine , sometimes it takes faxes with no problems.
on the retransmit , it took 3 faxes with no problems.
but some times it goes , silly, I suspect that it is just poor error handling by the panasonics, if the fax is good , it all works fine, if you get transmission errors then it falls apart.


If you do decide to send some test faxes that is fine, just remember it is gonig to cost you IDD to Hong Kong.

if this sort of thing is useful for you to improve hylafax, I can start sending them to you.

Steve


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




Project hosted by iFAX Solutions