Re: [hylafax-users] MPS - EOP errors....

[Lee Howard <faxguy@deanox.com>]

On 2002.03.13 20:30 Chris Parsons wrote:
> I've upgraded to 4.1.1 after completely removing hylafax 4.1. Hoping that
> this would solve the MPS - EOP errors. However I still get them.

They cannot be eradicated completely unless we have a fixed set of 
controlled recipients.  See:
http://www.hylafax.org/archive/2001-11/msg00164.html
for the last time I wrote a long explanation on this matter.  The patches 
discussed there are found in 4.1.1, so you don't need to try to get them 
now.

> Never
> had a
> problem with the eicon card in nt or when I use a CAPI to send it.

If you never had a problem before, why did you bother changing to HylaFAX 
or upgrading to 4.1.1?  I suspect that you're being a bit unfair.

> However
> the CAPI4Hylafax does not work either. (See my previous CAPI4Hylafax
> post).
> Im using an Eicon 4BRI card with the Eicon Diva Binary Drivers.

These drivers have as much influence as anything on the functionality of 
HylaFAX.

> I'm
> running
> them in class 1 mode. This works perfectly apart from a few of our
> clients
> fax machines.

If the clients are willing, we may want to try sending them a test fax 
from another HylaFAX system which would tell us whether it is a HylaFAX 
protocol problem, a disfunction with the remote, or if it is a 
configuration quirk with the Eicon drivers.

> Should I re-try the cvs version would it really make much
> difference. (Have that many changes been made since last release?)

There's only been one alteration to CVS after 4.1.1 and it has absolutely 
nothing to do with this.

....
> Mar 14 02:31:25.60: [10810]: USE 2-D MR
> Mar 14 02:31:25.60: [10810]: SEND training at v.29 9600 bit/s
> Mar 14 02:31:25.60: [10810]: <-- [9:AT+FTH=3\r]
> Mar 14 02:31:25.75: [10810]: --> [7:CONNECT]
> Mar 14 02:31:25.75: [10810]: <-- data [23]
> Mar 14 02:31:25.75: [10810]: <-- data [2]
> Mar 14 02:31:26.48: [10810]: --> [7:CONNECT]
> Mar 14 02:31:26.48: [10810]: <-- data [6]
> Mar 14 02:31:26.48: [10810]: <-- data [2]
> Mar 14 02:31:27.83: [10810]: --> [2:OK]
> Mar 14 02:31:27.83: [10810]: <-- [9:AT+FTS=7\r]
> Mar 14 02:31:27.83: [10810]: --> [2:OK]
> Mar 14 02:31:27.83: [10810]: <-- [10:AT+FTM=96\r]
> Mar 14 02:31:28.14: [10810]: --> [7:CONNECT]
> Mar 14 02:31:28.14: [10810]: <-- data [1024]
> Mar 14 02:31:28.14: [10810]: <-- data [776]
> Mar 14 02:31:28.15: [10810]: <-- data [2]
> Mar 14 02:31:29.70: [10810]: --> [2:OK]
> Mar 14 02:31:29.70: [10810]: <-- [9:AT+FRH=3\r]
> Mar 14 02:31:32.80: [10810]: --> [0:]
> Mar 14 02:31:32.80: [10810]: MODEM <Empty line>
> Mar 14 02:31:32.80: [10810]: <-- data [1]
> Mar 14 02:31:32.80: [10810]: --> [2:]
> Mar 14 02:31:32.80: [10810]: --> [2:OK]

This basically means that we just tried to train with the remote system at 
v.29 9600 bit/s and it failed.  You see that we communicate after +FTH=3 
at 300 baud (the rate at which frames are communicated during faxing), but 
when we switch to v.29 we don't hear the carrier at 9600 baud (thus the 
"Empty line").  So we retrain at a slower rate...

> Mar 14 02:31:32.80: [10810]: DELAY 1500 ms
> Mar 14 02:31:34.30: [10810]: SEND training at v.29 7200 bit/s
> Mar 14 02:31:34.30: [10810]: <-- [9:AT+FTH=3\r]
> Mar 14 02:31:34.39: [10810]: --> [7:CONNECT]
> Mar 14 02:31:34.39: [10810]: <-- data [23]
> Mar 14 02:31:34.39: [10810]: <-- data [2]
> Mar 14 02:31:35.12: [10810]: --> [7:CONNECT]
> Mar 14 02:31:35.12: [10810]: <-- data [6]
> Mar 14 02:31:35.12: [10810]: <-- data [2]
> Mar 14 02:31:36.47: [10810]: --> [2:OK]
> Mar 14 02:31:36.47: [10810]: <-- [9:AT+FTS=7\r]
> Mar 14 02:31:36.47: [10810]: --> [2:OK]
> Mar 14 02:31:36.47: [10810]: <-- [10:AT+FTM=72\r]
> Mar 14 02:31:36.79: [10810]: --> [7:CONNECT]
> Mar 14 02:31:36.79: [10810]: <-- data [1024]
> Mar 14 02:31:36.79: [10810]: <-- data [326]
> Mar 14 02:31:36.79: [10810]: <-- data [2]
> Mar 14 02:31:38.35: [10810]: --> [2:OK]
> Mar 14 02:31:38.35: [10810]: <-- [9:AT+FRH=3\r]
> Mar 14 02:31:41.44: [10810]: --> [0:]
> Mar 14 02:31:41.44: [10810]: MODEM <Empty line>
> Mar 14 02:31:41.44: [10810]: <-- data [1]
> Mar 14 02:31:41.44: [10810]: --> [2:]
> Mar 14 02:31:41.44: [10810]: --> [2:OK]

Again, the training fails with v.29 at 7200 baud.  This is not a good 
sign.  Generally this would mean that we have a very poor connection 
quality with this sytem.

> Mar 14 02:31:41.44: [10810]: DELAY 1500 ms
> Mar 14 02:31:42.94: [10810]: SEND training at v.27ter 4800 bit/s
> Mar 14 02:31:42.94: [10810]: <-- [9:AT+FTH=3\r]
> Mar 14 02:31:43.03: [10810]: --> [7:CONNECT]
> Mar 14 02:31:43.03: [10810]: <-- data [23]
> Mar 14 02:31:43.03: [10810]: <-- data [2]
> Mar 14 02:31:43.76: [10810]: --> [7:CONNECT]
> Mar 14 02:31:43.76: [10810]: <-- data [6]
> Mar 14 02:31:43.76: [10810]: <-- data [2]
> Mar 14 02:31:45.11: [10810]: --> [2:OK]
> Mar 14 02:31:45.11: [10810]: <-- [9:AT+FTS=7\r]
> Mar 14 02:31:45.11: [10810]: --> [2:OK]
> Mar 14 02:31:45.11: [10810]: <-- [10:AT+FTM=48\r]
> Mar 14 02:31:46.11: [10810]: --> [7:CONNECT]
> Mar 14 02:31:46.11: [10810]: <-- data [900]
> Mar 14 02:31:46.11: [10810]: <-- data [2]
> Mar 14 02:31:47.67: [10810]: --> [2:OK]
> Mar 14 02:31:47.67: [10810]: <-- [9:AT+FRH=3\r]
> Mar 14 02:31:48.39: [10810]: --> [7:CONNECT]
> Mar 14 02:31:49.56: [10810]: --> [2:OK]
> Mar 14 02:31:49.56: [10810]: TRAINING succeeded

Okay, so after a bit of struggle, we just succeeded in training with v.27 
at 4800 baud.

> Mar 14 02:31:49.56: [10810]: DELAY 75 ms
> Mar 14 02:31:49.63: [10810]: <-- [10:AT+FTM=48\r]
> Mar 14 02:31:50.64: [10810]: --> [7:CONNECT]
> Mar 14 02:31:50.64: [10810]: SEND begin page
...
> Mar 14 02:32:21.07: [10810]: SENT 25868 bytes of data
...
> Mar 14 02:32:45.41: [10810]: SENT 14511 bytes of data

Okay, the data seems to actually be going out at proper 4800 baud.

> Mar 14 02:32:45.41: [10810]: SEND 2D RTC
> Mar 14 02:32:45.41: [10810]: <-- data [30]
> Mar 14 02:32:45.41: [10810]: <-- data [2]
> Mar 14 02:32:45.41: [10810]: SEND end page
> Mar 14 02:32:58.05: [10810]: --> [2:OK]
> Mar 14 02:32:58.05: [10810]: <-- [9:AT+FTS=9\r]
> Mar 14 02:32:58.05: [10810]: --> [2:OK]
> Mar 14 02:32:58.05: [10810]: SEND send EOP (no more pages or documents)
> Mar 14 02:32:58.05: [10810]: <-- [9:AT+FTH=3\r]
> Mar 14 02:32:58.15: [10810]: --> [7:CONNECT]
> Mar 14 02:32:58.15: [10810]: <-- data [3]
> Mar 14 02:32:58.15: [10810]: <-- data [2]
> Mar 14 02:32:59.45: [10810]: --> [2:OK]
> Mar 14 02:32:59.45: [10810]: <-- [9:AT+FRH=3\r]
> Mar 14 02:33:02.54: [10810]: --> [0:]
> Mar 14 02:33:02.54: [10810]: MODEM <Empty line>
> Mar 14 02:33:02.54: [10810]: <-- data [1]
> Mar 14 02:33:02.54: [10810]: --> [2:]
> Mar 14 02:33:02.54: [10810]: --> [2:OK]
...
> Mar 14 02:33:11.50: [10810]: No response to MPS or EOP repeated 3 tries

Well, after training we never really heard again from the remote.  So... 
it would be helpful to know if they actually get the page or not.  If they 
don't get the page, then you may want to try changing Class1TCFWaitCmd to 
"AT+FTS=9" either in your config file or in DestControls.  If they do get 
the page, then maybe try changing Class1EOPWaitCmd to "AT+FTS=10".  If 
this works, then you're really only looking at a timing issue, and you'll 
need to keep an eye on your statistics to see where your configuration 
settings work best.  You should be able to tune perfectly for controlled 
and fixed clients with DestControls.

If this doesn't work, then I suspect that there is either a problem with 
your Eicon drivers or the remote fax machine in handling v.29, v.27, or 
2DMR.  I would recommend that you try using "Use2D=no" in your 
DestControls for this destination to check on the 2DMR compatibility.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null