Re: [hylafax-users] check modem power

[David Coles <davidc@southern.com>]

Hi.

I'm CC:ing this to hylafax-devel, as I have a workaround the problem I
have been having for their consideration.

Recently we have been having problems trying to get HylaFAX to work with
SGI (Digi) EtherLite terminal servers.

The problem manifests itself as "Unknown problem (check modem power)"
errors when trying to send faxes.

I've tracked this down to the ATE0 command failing to be recognised by the
modem:

Jul 26 16:22:35.84: [38373]: MODEM flush i/o
Jul 26 16:22:35.84: [38373]: <-- [15:ATE0V1Q0S0=0H0\r]
Jul 26 16:22:40.85: [38373]: MODEM TIMEOUT: reading line from modem
Jul 26 16:22:40.85: [38373]: MODEM <Timeout>
Jul 26 16:22:40.85: [38373]: <-- [5:ATM0\r]
Jul 26 16:22:40.93: [38373]: --> [4:ATM0]

This leads to all susequent commands being echoed, confusing HylaFAX and
leading to an error.

I had not managed to reproduce the error with packages like Efax, which
is, I believe down to HylaFAX's tendancy to open and close the modem
device repeatedly prior to sending a fax.

HylaFAX opens the comms device with the O_NDELAY - open(2) man page:

            When opening a file associated with a communication line:

                    If O_NDELAY or O_NONBLOCK is set:  The open will return
                    without waiting for the device to be ready or available;
                    subsequent behavior of the device is device specific.

Now, I don't know what the Right Way is here, but it would seem that after
closing the device, the EtherLite remains in some kind of undefined state
for a short period, and opening it again quickly results in the first
command sent to it being lost - is HylaFAX being overly reliant on the
status of the device, or is the EtherLite driver taking poetic license
with this definition and wrongly extending it the case where the device is
opened successfully?

Anyway, I added a "sleep(1);" line to the very top of ModemServer::openDevice
in ModemServer.c++ and the problem goes away - the terminal server
presumably has enough time to flush buffers or whatever it has to do and
restore the line to a sane state.

Using HylaFAX on the modems connected directly to the hardwired serial
ports or Digi SCSI terminal servers has never revealed this problem
before, but perhaps that is only due to network latency and stuff?

I welcome your opinions, and thank you for your time reading this and
contributing to HylaFAX :)

--
David Coles, System Administrator, Southern Studios    davidc@southern.com



____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null