Re: [hylafax-users] Bad HDLC terminating flag received.

[Arthur <arthur@xxxxxxxxxxxx>]

It is a US Robotics modem - there doesn't seem to be any kind of model
specification, but in the logs, it reports itself as "Model U.S.
Robotics 56K FAX EXT V5.11.6."  The other modem, a Global Village Series
0269 Faxmodem works fine. 

We upgraded to 4.2.0 release (we were running RC2), but it made no
difference.  What's interesting is that the US Robotics modem fails in
different ways for different protocols (the bad HDLC terminating flag
messages for 2D-MMR, and T.30 T2 timeouts like those seen below for 2D
MR), but it always fails.  I changed RecvDataFormat to "1D-MR" from the
default of "adaptive" to force the modem to choose that, but it seems
that only affects the output TIFF format, not the actual transfer
protocol with the remote fax machine? 

Here's another log of a failed fax, this time using 2D-MR rather than
2D-MMR. 

Any ideas, anyone?

Thanks,

Arthur
Sep 24 18:39:16.25: [  227]: SESSION BEGIN 000000430 12129295946
Sep 24 18:39:16.25: [  227]: HylaFAX (tm) Version 4.2.0rc2
Sep 24 18:39:16.25: [  227]: <-- [13:AT+FCLASS=1A\r]
Sep 24 18:39:21.80: [  227]: --> [7:CONNECT]
Sep 24 18:39:21.80: [  227]: ANSWER: FAX CONNECTION  DEVICE
'/dev/cu.USA28X181P1.1'
Sep 24 18:39:21.80: [  227]: RECV FAX: begin
Sep 24 18:39:21.80: [  227]: <-- data [35]
Sep 24 18:39:21.80: [  227]: <-- data [2]
Sep 24 18:39:21.94: [  227]: --> [7:CONNECT]
Sep 24 18:39:21.94: [  227]: <-- data [23]
Sep 24 18:39:21.94: [  227]: <-- data [2]
Sep 24 18:39:22.66: [  227]: --> [7:CONNECT]
Sep 24 18:39:22.66: [  227]: <-- data [10]
Sep 24 18:39:22.66: [  227]: <-- data [2]
Sep 24 18:39:24.85: [  227]: --> [2:OK]
Sep 24 18:39:24.85: [  227]: <-- [9:AT+FRH=3\r]
Sep 24 18:39:25.29: [  227]: --> [7:CONNECT]
Sep 24 18:39:26.68: [  227]: --> [2:OK]
Sep 24 18:39:26.68: [  227]: REMOTE TSI "Tekserve +1212463928"
Sep 24 18:39:26.68: [  227]: <-- [9:AT+FRH=3\r]
Sep 24 18:39:26.70: [  227]: --> [7:CONNECT]
Sep 24 18:39:27.08: [  227]: --> [2:OK]
Sep 24 18:39:27.08: [  227]: REMOTE wants 14400 bit/s
Sep 24 18:39:27.08: [  227]: REMOTE wants A4 page width (215 mm)
Sep 24 18:39:27.08: [  227]: REMOTE wants unlimited page length
Sep 24 18:39:27.08: [  227]: REMOTE wants 7.7 line/mm
Sep 24 18:39:27.08: [  227]: REMOTE wants 2-D MR
Sep 24 18:39:27.08: [  227]: RECV training at v.17 14400 bit/s
Sep 24 18:39:27.08: [  227]: <-- [11:AT+FRM=145\r]
Sep 24 18:39:28.95: [  227]: --> [7:CONNECT]
Sep 24 18:39:30.51: [  227]: RECV: TCF 2813 bytes, 3% non-zero, 2700
zero-run
Sep 24 18:39:30.51: [  227]: --> [6:NO CER]
Sep 24 18:39:32.51: [  227]: MODEM <Timeout>
Sep 24 18:39:34.51: [  227]: MODEM <Empty line>
Sep 24 18:39:36.52: [  227]: MODEM <Empty line>
Sep 24 18:39:36.52: [  227]: DELAY 75 ms
Sep 24 18:39:36.59: [  227]: TRAINING succeeded
Sep 24 18:39:36.59: [  227]: <-- [9:AT+FTH=3\r]
Sep 24 18:39:36.79: [  227]: --> [7:CONNECT]
Sep 24 18:39:36.79: [  227]: <-- data [3]
Sep 24 18:39:36.79: [  227]: <-- data [2]
Sep 24 18:39:37.96: [  227]: --> [2:OK]
Sep 24 18:39:37.96: [  227]: <-- [11:AT+FRM=146\r]
Sep 24 18:39:44.97: [  227]: <-- data [1]
Sep 24 18:39:45.08: [  227]: --> [2:OK]
Sep 24 18:39:45.08: [  227]: RECV FAX (000000430):
recvq/fax000000041.tif from Tekserve +1212463928, route to
<unspecified>, 0 pages in 0:24
Sep 24 18:39:45.08: [  227]: RECV FAX: T.30 T2 timeout, expected page
not received
Sep 24 18:39:45.08: [  227]: <-- [9:AT+FTH=3\r]
Sep 24 18:39:45.23: [  227]: --> [7:CONNECT]
Sep 24 18:39:45.23: [  227]: <-- data [3]
Sep 24 18:39:45.23: [  227]: <-- data [2]
Sep 24 18:39:46.40: [  227]: --> [2:OK]
Sep 24 18:39:46.40: [  227]: RECV FAX (000000430): session with Tekserve
+1212463928 terminated abnormally: T.30 T2 timeout, expected page not
received
Sep 24 18:39:46.40: [  227]: RECV FAX: bin/faxrcvd
"recvq/fax000000041.tif" "cu.USA28X181P1.1" "000000430" "T.30 T2
timeout, expected page not received" "" ""
Sep 24 18:39:46.40: [  227]: RECV FAX: end
Sep 24 18:39:46.40: [  227]: SESSION END

On Fri, 2004-10-01 at 16:16, Lee Howard wrote:
> On 2004.10.01 12:50 Arthur wrote:
> > I suppose it does.  Another example log says [7: CARRIER] instead.
> > Maybe some sort of system log hiccup.  It looks like I had
> > accidentally
> > enabled logging of modem I/O, which I'm now learning can muck up
> > timing
> > to some extent.  No idea though whether this will make a difference.

> > The funny thing is, I look through logs of received faxes that DID
> > work,
> > and they all say NO CARRIER there as well, rather than OK. The bad
> > ones
> > just seem to timeout and then start freaking out...
> 
> I don't think it's a logging error.  I think your modem is really 
> reporting messed up NO CARRIER responses.  What kind of modem is it?
> 
> 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*