HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: modem state for other programs



D. Hugh Redelmeier wrote:
    
    I am using hylafax-v4.0pl0 under Solaris 2.5.  I am trying to install
    my new Motorola ModemSURFR 28.8 modem (class 2).  It is mostly
    working, but I have a few problems.  This note is about one of them.
    
    I run faxgetty, letting it adaptively answer the phone (I haven't
    yet tested whether an inbound data call works).  I use tip and
    uucp outbound.  Since I've installed the new modem, tip is no longer
    able to dial out; I've adjusted uucp's Dialers entry so that it does
    work.
    
    I *think* what is happening is that faxgetty leaves the modem in a
    state that isn't suitable for tip.  Perhaps it has to to do adaptive
    answer.

faxgetty(1M) sets the modem for incoming calls and is waiting
for "RING". If tip takes the modem it is responsible from now
for all and *must* set the modem to fit its needs.
    
    My evidence is from testing with a tip to connect to the raw modem
    (tip to an entry that looks like
    	usrnhf:\
    		:dv=/dev/cua/a:br#38400:
    ).  When I manually dial the number, I get a "+FCON" response from the
    modem.  tip's dialer is not really configurable, so I can't convince
    it to deal with this.
    
    My solution for uucp is to add an ATZ at the start of the Dialer
    string.  This seems to reset things to the state I stored as the reset
    state.
    
    Is my analysis correct?

Yes and you could also reset the modem to factory defaults
with AT&F (or similar for your modem). Keep in mind that some modems
don't like anything else on the same command line together with
ATZ or AT&F (some modems are clearing the command-line buffer
during ATZ before parsing the items which follow ATZ). The best way
is sending AT&F (or similar for your modem) to reset to factory
defaults, wait for OK and then send down all settings you want
to change.
    
    Is there a correct way to get faxgetty to reset the modem state when
    an outbound program wants to use it?

No. faxgetty(1M) listens to the modem line. If there is anything
to read faxgetty(1M) checks the lock for the modem *before*
reading anything from the line; if there is no other process
with a lock for the modem it creates a lock itself and does
read-in the message (e.g. "RING") from the modem and processes
the message (e.g. counting the RING's to decide to pick-up the call);

In case of outbound usage the other proc should create the lock.
If it doesn't create a lock (or create it on some other place
as faxgetty(1M) is locking for) and sends an AT-cmd down to the
modem the following would happen: the modem is responding to
the command and both proc (e.g. tip and faxgetty(1M)) would do
a racing to read the response OK or ERROR etc.

Despite of the fact of this racing what should faxgetty(1M) do
if it sees a OK message from the modem which is a response
to the AT-command from tip? And how should it set now anything
usefull into the modem (may be tip doesn't like this setting
because it has just set something else)?

BTW: The racing described above is the typical situation where many
HylaFAX users without understanding of how faxgetty(1M) works are
complaining here in the list about "Waiting for modem come ready".

        matthias
-- 
firm: matthias.apitz@softcon.de [voc:+49-89-61308-351, fax: +49-89-61308-188]
priv: guru@thias.muc.de
 WWW: http://www.softcon.de/~guru/ OR http://www.guug.de/GUUG/firmen/apitz/

I'm away from Saturday, Jan. 4 to Jan. 14 for USENIX '97 Conference in Anaheim.




Project hosted by iFAX Solutions