Re: [hylafax-users] seeing problems on panasonic faxmachine

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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.


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