Re: [hylafax-users] T.30 T2 timeout, expected page not received

["Phillips, Steve M. (IA)" <SMPhillips@xxxxxxxxxxxxxx>]

Basically here is what I got from Comtrol:
"There is one known issue that may be causing this problem, but its usually
just the RocketPorts not the RocketModems. But we can give it a try.
 
You will need to have the kernel source for your running kernel and be able
to compile a module against it.
 
Download the latest linux driver from out website and replace the rocket.c
file with the one I am attaching to this message.
 
This issue will be fixed in the next version of the driver."

I did what was requested and recompiled the driver. It does appear to
functioning better but is still far from perfect. 

Steve

-----Original Message-----
From: Lee Howard [mailto:faxguy@xxxxxxxxxxxxxxxx] 
Sent: Wednesday, June 09, 2004 10:59 AM
To: Phillips, Steve M. (IA)
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] T.30 T2 timeout, expected page not received

On 2004.06.09 05:36 "Phillips, Steve M. (IA)" wrote:

> I have a Comtrol 8-port Rocketmodem III.
> I am getting many T.30 T2 timeout, expected page not received errors.

> I have contacted Comtrol who have a new driver in the works but they
> helped
> me apply a fix which has improved the situation.

What fix did Comtrol help you apply?

I used a RocketModem III for a few months in a testing environment with 
no noticeable problems and so I moved it to a production environment.  
Almost immediately I began experiencing problems.  No-response timeouts 
were just a part of it.  I ended up having to replace it until Comtrol 
gets that new driver out, but it has been several months now.  I think 
that the delay is that they are waiting on the DSP code provider.  The 
chipset change between RocketModem IIs and IIIs was not fax-friendly.

So much for my testing.  Part of the problem with the testing 
environment was that phone lines were limited, and the modem, unlike 
most other modems, requires an actual phone line in order to either 
call, answer, or both (I didn't ever determine which).  So it made 
testing very resource-demanding.  But, the problem is quite sporadic, 
and seems to get much worse only after some internal event happens, and 
I don't know if I could have ever had that "event" occur in the lab.

> Jun 08 13:40:44.27: [14933]: <-- [11:AT+FRM=146\r]
> Jun 08 13:40:51.27: [14933]: MODEM TIMEOUT: reading line from modem

Realistically speaking, the modem shouldn't wait 7 seconds before 
telling us +FCERROR, NO CARRIER, ERROR, or CONNECT.  But, like many 
other modems, it will, depending on what the remote is doing.  The 
problem here is that by the time 7 seconds elapse there is really no 
way to reliably recover, and so we hang up and expect them to call 
again.

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*