Re: Waiting for modem to come ready

[Matthias.Apitz@SOFTCON.de (Matthias Apitz)]

Gabriel Fernandez wrote:
    
    Hi:
    
       I read Q96 and Q126 from the updated FAQ list and they don't really
    answer my questions.
    
       First, when Sam said in August 1996 "USR's Class 2.0 fax firmware is
    notoriously substandard.  If you intend to depend on a modem for facsimile
    communication you should look at the documentation for recommendations on
    modems that are thought to be good." What did he really mean with that?
    
       I am already stuck with the modem (the same as many other people). I am
    not going to by a new modem just to send faxes. I would rather buy a fax
    machine. Does HylaFAX not support USR Courier modems completely and
    that's why many problems occur with both Class 1 and Class 2.0? Should I
    wait for an upgraded firmware in order to be able to send faxes with
    HylaFAX? Or, the affirmation above is completely outdated and errors
    should not be expected?

I've no USR modems and I can't say anything about them. My answer
is only a technical point of view about HylaFAX and fax standards.

The Class 1, 2 and 2.0 standards describe in detail
how a fax modem should work regarding the AT-commands, responses,
timings and so on. HylaFAX claimes to follow these standards and maybe
there are bugs in HylaFAX too (I've found one just a few days ago).
Whether or not HylaFAX follows the standard could be found in the
server- and session-tracing by comparing them with the spec and or
other books about these standards.

Whether your modem follows the "rules" can also be checked in these
traces. So it's "easy" (just compare a session trace with the
spec) to deside which part (modem or HylaFAX) is wrong.

On the other side if you have a given modem and a software driving
this modem and sending the pages as you want does not say anything
whether your modem follows the specs.
    
       My point is: I am able to send and receive faxes with my USR Courier
    V.Everything modem flawlessly using other software. Tha fact that HylaFAX
    might not be able to do so seems to me unreasonable.

For me this is reasonable. If the modem manufacter XXX sells a modem
and a fax software for this modem and both are not following the
standards it may be that this modem+software work while HylaFAX
and the modem don't work. Once again: I'm not saying that USR does so.
    
       Second, which is basically the reason of this mail. My modem is always
    "Waiting to come ready". Nico explained that the reason is because the
    same modem is used by several programs. In my case, they are PPP, a comm.
    package (Minicom under Linux), and HylaFAX. Nico said "to let Hylafax act
    as the line handler and start up getty's as necessary, and use the vastly
    more universal UUCP file-locking to protect the modem from two 
    simultaneous uses". However, it seems to me that 'faxgetty' has to do with
    the problem more than just the locking system. If I run 'faxgetty', then
    the message changes to "Waiting for modem to come free", which makes more
    sense to me.
    
       So, the final question is:
    
       What are the programs that should be run and how should they be run to
    have a consistent fax sending/receiving STANDALONE system? My situation is
    a personal computer with Linux that eventually sends and receives faxes.

If you share your modem line between faxgetty(1M) -  and you can't
receive faxes without faxgetty(1M) - and other applications (like
Minicom, cu, kermit) you *must* insure that only one proc talks
(in the sense of read(2) sys call) to the modem. Each proc which
wants to read data from the modem must lock the modem *before* (if it
isn't already locked) the read operation. All proc must use the same
locking style. That's all.

Once again the problem can be checked with the server traces and
(under Linux) with the command strace(1) to see which lock-files
are used and who is the winner of the racing.

There was a bug in v4.0pl0 saying "Waiting for modem to come ready"
if you used faxgetty(1M) with RingsBeforeAnswer set to zero. The bug
is fixed in v4.0pl1.

If you have problems with v4.0pl1 with "come ready" / "come free"
collect traces and we'll work-out the problem.

	matthias