FAX Recieve error after waiting for EOL

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

John M Kodis wrote:
> I managed to solve a couple problems that I was having with 
> mgetty+sendfax v1.1.9 under Linux 2.0.31. 
> 
> It appears that in order to get sendfax to use XON-XOFF flow control, 
> I have to use the stty to turn this on rather than specifying it in 
> the policy.h file. Has anyone else reported this? It seems odd.

This would surprise me. Stty is not doing anything different from what
sendfax does.

Can somebody test this, and confirm/deny this? I don't have a Linux
box with a fax modem at hand right now.

(I *can* confirm that the flow control code works fine with IBM AIX, but
this fact is pretty worthless as AIX is one of those special-case
operating systems...)

> I was also able to get around the immediate "NO CARRIER" condition 
> after mgetty picks up an incoming fax by insuring that the sending fax 
> turns on its carrier before mgetty picks up the call. 

Yes, this is necessary for some fax modems that insist on the calling tone
(CNG) from the calling fax.

> This allows 
> mgetty to begin receiving a fax, however the log looks like something 
> isn't quite right after issuing the DC2 and waiting for EOL. The fax 
> reception aborts with an ERROR string shortly thereafter.

Let's look...

> 10/22 10:21:59 yS2 mdm_command: string 'AT+FLO=2' 
> 10/22 10:21:59 yS2 mdm_command: string 'OK' -> OK 
> 10/22 10:21:59 yS2 fax_send: 'AT+FDR'

Looks good so far.

> 10/22 10:21:59 yS2 fax_wait_for(CONNECT)
> 10/22 10:22:00 yS2 fax_wait_for: string 'AT+FDR'
> 10/22 10:22:03 yS2 fax_wait_for: string 'CONNECT'** found ** 
> 10/22 10:22:03 yS2 sending DC2
> 10/22 10:22:03 yS2 fax_get_page_data: wait for EOL, got: 
> [0a][e0][ad][ef][8b][[8e][cb]N[ef][f5][06][f2]89[93][c7][01][b9]"{ 
> [c4][a5][e4][1c][09]}e[15]p[1c]u6,&[c1][9f][b7][bf][19]Wf6Qz[c2]n 
> [94]Z[d8][be]A[16][ff][87][ca][d8]'[9e]p[ab]R[f9][ad]qI[d2][a4]0#/ 
> [bb]U~DO2[c7]g=[c0][c2]\[12][06][d9]Z[7f]2j[b8][ca]g`[fb]7G[ab][e0] 
> [ce]_a!V[e5][ee][b7][95]K[c7][1f][9f][e2]s[10]
> 10/22 10:22:03 yS2 fax_get_page_data: receiving 

This is pretty strange. There should not be more than maybe 2-10 bytes of
"junk" before the page starts. I have seen this in some USR firmware
versions that had bad start-of-page timing.

> /var/spool/fax/incoming/fn44e0bf6S2-_-3013060963_.01...
> 10/22 10:22:05 yS2 fax_get_page_data: page end, bytes received: 2142 

2142 bytes is pretty short.

> 10/22 10:22:05 yS2 fax_wait_for(OK)
> 10/22 10:22:05 yS2 fax_wait_for: string '+FPS:1,10,0,0,0' 
> 10/22 10:22:05 yS2 page status: +FPS:1,10,0,0,0
> 10/22 10:22:05 yS2 16 lines received, 0 lines bad, 0 bytes lost 

and 16 lines is also pretty short (but 2142 bytes would usually be more
than 16 lines).

> 10/22 10:22:13 yS2 fax_wait_for: string 'ERROR'
> 10/22 10:22:13 yS2 ABORTING: line='ERROR' 
> 10/22 10:22:13 yS2 fax receiver: hangup & end

I think your modem's fax implementation is pretty broken.

It MUST NOT send any "ERROR" string in the middle of a transaction. ERROR
is only a valid response if the host sends an AT command that is not
understood.

The "weird things" seen above second that assumption.

I think the only thing you can do is to ask your modem vendor whether they
have a firmware upgrade available (and if not, return the modem).

gert

-- 
USENET is *not* the non-clickable part of WWW!
           //www.muc.de/~gert/
Gert Doering - Munich, Germany      gert@greenie.muc.de
fax: +49-89-3545980     gert.doering@physik.tu-muenchen.de
.