sendfax cannot send several faxes in a row (ELSA Mikrolink 56k)

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

Hi,

set "open-delay 500" in sendfax.config.  This will take care of all
pending stuff in the modem queue, and give the modem .5 seconds time to
settle down.

The reason why sendfax doesn't wait for "OK" after sending AT+FCLASS=0 is
that many modems have hung up (DCD low) at that place, and you won't be
able to *get* the OK response from them.

The second "OK" you observed is sent by the ELSA upon DTR changing to
"high", there's nothing sendfax can do about it, except wait a while, and
then flush its input queues:

    /* some modems send an "OK" after DTR is raised - catch it
     */
    if ( c_isset(open_delay) )
    {
        lprintf( L_NOISE, "pausing %d ms", c_int(open_delay));
        delay(c_int(open_delay));               /* give modem time to settle */
    }
    tio_flush_queue(fd, TIO_Q_BOTH);            /* clear junk */


gert


Joachim Wesner wrote:
> Hi,
> 
> I use an ELSA Mikrolink 56k with mgetty+sendfax 1.00 or 1.1.8 on
> Intel Linux 2.0.33. NO special setup in policy.h or sendfax.config
> besides ignore-carrier yes.
> 
> I notice the following problem with both of the above versions:
> 
> If I send or poll *one* fax, everything works nice. If I send another
> fax, without "touching" (see below) the modem-line otherwise, the second
> time sendfax starts dialing and immediately hangs up again. On the third
> try, sendfax locks up and you cannot "revive" the modem even with
> another terminal program (minicom) and you have to switch it off and on
> again.
> 
> I could trace the problem down to the following: When sendfax ends, it
> calls fax_close in sendfax.c. This subroutine sends "AT+FCLASS=0"
> to the modem, but does *never* read in the response. Why ???
> It seems that the "OK" the modem will send remains in the input queue,
> even if sendfax close the device file.
> 
> Indeed, when you start minicom in between each fax sending, you see that
> there are up to *TWO* instances of "OK" still in the input buffer.
> When you start sendfax now, after using minicom to "flush" the line,
> you can send another fax without problems. And so on....
> 
> Also, by studying the log-file in the second erroneous sendfax attempt
> (without minicom), you can see that the surplus OK response(s) cause(s)
> chaos in the send-reply sequences sendfax expects, because it gets
> the response to the command sent one or 2 lines earlier.
> 
> Unfortunatelly, sendfax does not allow the use of an init-chat (as
> mgetty) to flush anything that might be lurking in the input.
> 
> I also tried patching the software a bit, and used
> mdm_command("AT+FCLASS=0", fd) instead of fax_send in fax_close, but it
> did not help, probably because it only removes one "OK", I did not yet
> find where the other unacknowledged "OK" is caused. 
> Using clear_line failed, because it requires more changes in the header
> files and I do not yet understand enough of the program stucture.
> 
> What can I do ???
> 
> 
> Greetings,
> 
> Joachim
> 


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