Re: [hylafax-users] Failed to properly open control V.34 channel

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.06.29 12:19 Kris Henderson wrote:

> Jun 26 03:43:58.90: [16690]: <-- <2:10 6D>
> Jun 26 03:44:08.04: [16690]: --> <2:10 04>
> Jun 26 03:44:08.04: [16690]: EOT received (end of transmission)
> Jun 26 03:44:08.04: [16690]: Failed to properly open control V.34
> channel.

Yeah, this is the worst-case scenario.  Basically we send image data, 
and request to open the the control channel (<DLE><0x6D>), and then 10 
seconds later we get EOT (<DLE><0x04>) which means that the V.34 
connection has been terminated (i.e., the remote hung up).

Most likely this is something that MultiTech is going to have to look 
at, if it is reproducible.  I suppose that it is possible that HylaFAX 
is sending some uniquely bad image data to it (i.e., are you testing 
with multi-strip MMR image data?), somehow, and that's messing up the 
receiver.  That seems unlikely, though.

> This logfile is from a slightly older version of HylaFAX that I have
> modified, I sent a two page fax.  It looks like the first page made it
> ok and most of the second page was sent before the error occurred.
> When
> I saw the error happening in my code I tried it in the CVS version of
> HylaFAX and saw it happen there, though the last 10 or so faxes I've
> sent using the CVS version do not have this error.  Is there anything
> that might have changed in the last month or two that would make this
> error less likely in the CVS version of HylaFAX?

It's possible, but I don't know what it could have been.

> Could timing make
> this
> error more likely to occur, for example if an operation in Phase B or
> C
> takes 1 or 2 seconds longer than it used to?

In V.34 there really is no DTE-imposed timing restrictions that I can 
think of.  I don't think that "timing" is the issue.  I suspect that 
it's something that the manufacturer is going to have to discover.  
Once that happens then the circumstances of its occurrence will be made 
manifest.

> I can send the entire
> log
> to anyone interested in seeing it but it is almost 9MB.

I don't think that would help much.  At this point you have to rely 
upon the manufacturer, or get lucky in discovering a condition that 
will not cause the error, and then do something to make sure that 
condition always occurs.

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*