Re: [hylafax-users] Duxbury (conexant-based) modem problems

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

David Wilson wrote:

> Jun 26 11:24:34.23: [27519]: --> [7:CONNECT]
> Jun 26 11:24:34.96: [27519]: --> [2:OK]
> Jun 26 11:24:34.96: [27519]: REMOTE CSI "StarRate I.T."


Okay, we get CSI...

> Jun 26 11:24:34.96: [27519]: <-- [9:AT+FRH=3\r]
> Jun 26 11:24:34.97: [27519]: --> [7:CONNECT]
> Jun 26 11:24:42.80: [27519]: --> [2:OK]
> Jun 26 11:24:42.80: [27519]: HDLC frame with bad control field 0x80


This is interesting.  The control field here should have been 0xC0 or 
0xC8 and it's extremely unlikely (although I guess possible) that the 
sender errored here.  If the sender did not err then it means that the 
modem did not do FCS checking correctly otherwise there would be an 
ERROR result and not an OK result.  It may be interesting to see the 
outcome of setting this in your modem configuration file:

 Class1ValidateV21Frames: yes

That should be able to give us a definitive answer in cases like this as 
to whether or not the modem or the remote fax device is at fault.

I guess that there is an extremely remote chance that the FCS checking 
passed but the HDLC frame was still corrupt.  I'm not sure of the 
mathematical probability there, but I expect that it is fairly remote.

> Jun 26 11:24:46.53: [27519]: <-- [9:AT+FRH=3\r]
> Jun 26 11:24:46.54: [27519]: --> [7:CONNECT]
> Jun 26 11:24:47.23: [27519]: --> [2:OK]
> Jun 26 11:24:47.23: [27519]: REMOTE CSI "031 5636119"


I find it a bit curious that the receiver changes its CSI response after 
repeating it.  Just curious.

> Jun 26 11:25:22.87: [27519]: <-- [9:AT+FRH=3\r]
> Jun 26 11:25:23.11: [27519]: --> [7:CONNECT]
> Jun 26 11:25:24.24: [27519]: --> [2:OK]
> Jun 26 11:25:24.24: [27519]: SEND recv RTN (retrain negative)


Judging by what comes after this, the receiver here probably intended 
RTN to mean RTP.  Meaning, the receiver probably printed out the page 
just fine.  It's a common RTN problem.  See 'man hylafax-config' under 
RTNHandlingMethod for more information.

> Jun 26 11:25:29.73: [27519]: <-- [9:AT+FRH=3\r]
> Jun 26 11:25:32.83: [27519]: --> [0:]
> Jun 26 11:25:32.83: [27519]: MODEM <Empty line>
> Jun 26 11:25:32.83: [27519]: <-- data [1]
> Jun 26 11:25:33.03: [27519]: MODEM <Timeout>
> Jun 26 11:25:33.03: [27519]: DELAY 1500 ms


This indicates that the modem doesn't properly know how to "abort" 
receptions.  You may need to put this in your modem config file to 
compensate:

 Class1RecvAbortOK: 0

> LOG-2
>
> Jun 26 13:39:07.26: [17481]: <-- [9:AT+FRH=3\r]
> Jun 26 13:39:12.25: [17481]: --> [2:OK]


Your SessionTracing value is too low for me to make any conclusions 
about this log.  Try this instead:

 SessionTracing:  0xFFF

> LOG-3
>
> Jun 26 11:52:08.64: [ 4589]: No response to EOP repeated 3 tries


On this one, do you know if the receiver printed out the page?  It's so 
hard to know what went wrong from merely looking at the sender's log.  
I'd also be interested to see here how HylaFAX+ performs.

> LOG-4


Nothing wrong with this one.

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*