Re: flexfax: Wedged modems and reticent faxq

[Glenn Burkhardt <glenn@aoi.ultranet.com>]

> We continue to have problems with our Hylafax 4.0pl2 solaris 2.6
> servers, which pump out thousands of pages of research reports to
> our clients each day:
> 

This level of service probably deserves modems at the $300 price point.  They
have much better error recovery.  I think the MultiTech BA series, and the USR
Courier modems fall into this class.

> 	o Our modems (we use MultiTechs ranging from the MT2834MR6
> 	  to some older models) work as expected, but over time
> 	  they 'wedge' one by one.  Only power cycling the modem
> 	  returns them to a responsive state.  I have initialized
> 	  each modem with the following commands, which should
> 	  reset the modem to a known state when DTR goes low:
> 
> 		ATE1V1Q0X4&D3&SF1&S0&C0&F9&W0
> 
> 	  This makes wedging more infrequent, but does not fully
> 	  solve the problem.
> 

So, either the modem or the serial port are hanging.  Although the modem is the
prime suspect, since power cycling it cures the problem, the serial port 
driver
could also be hanging.

Can you verify that the modem is hung with some other program, e.g., kermit,
when this happens?  Can you see the TR lamp going on and off, when faxgetty
tries to get a response from the modem?  

Why are you disabling DSR activity with &S0 and &SF1 ?  These are not the 
factory
default settings.  What happens when you use the factory default settings for 
DSR handling?

I had a similar problem with newer MultiTech ZDX models hanging, not responding
the DTR toggles, and requiring a power cycle.  But it was after data 
connections
terminated due to poor line conditions.  Working with MultiTech customer 
support,
we learned that the &C4 setting (reset on carrier drop) cured the problem.

Have you checked the log files for the last session prior to the hang?  I'd
like to see 3 or 4 of them to see if there's a pattern.  Be sure to set the
Modem Operations and Modem Communications flags in the SessionTracing variable
(see config(5)).

For the record, what multiport board are you using?  And do try Mr. Ashworth's
suggestion of trying a serial port on the motherboard (that will use a driver
Sun wrote).

> 
>	o The 'wedge' command does not fix the above.  (Probably
>	  because the modem becomes completely unresponsive.)  The
>	  following error message is repeated in /var/adm/messages:
>
>		MODEM /dev/sts/ttyD0b appears to be wedged
>
>	  Isn't faxq supposed to take the modem out of service???
 
It has taken it out of service.  You can reduce the frequency of the messages
to the log with the MaxSetupAttempts parameter in the /var/spool/fax/etc/config
file (see config(5)).  You can alter the behavior of the system with a wedged
modem by changing the script /var/spool/fax/bin/wedged.


> 
> 	o Possibly related to the above, 'faxquit' only kills 'faxq'
> 	  if there are no currently running 'faxsend' processes.  If
> 	  there ARE faxsend processes running, faxq just keeps on
> 	  spawning new faxsends instead of waiting for the running
> 	  processes to finish and then exiting.  'faxstate' doesn't
> 	  reliably allow me to mark a modem out of service.  It
> 	  seems the whole business of modem status doesn't seem to
> 	  be working correctly.
> 

Agreed.  Modem status reporting/control needs some work.  But I'm able to 
disable modem use with faxstate - what precisely happens for you?

> 	  In spite of the fact that we use HylaFAX as an outbound
> 	  fax server only, I have tried running the system using
> 	  'faxgettys' and 'faxmodem'.  Neither approach solves these
> 	  problems.
> 
> 
> We have been using HylaFAX on five Ultra 2s with 96 modems on each
> server.  I have come to the conclusion that the software is not
> production ready for the quantities of faxes that we generate.  We
> may have to abandon Hylafax and go back to a commercial product if we
> can't get Hyla to work reliably.

Ah, the glove has been thrown down!

IMHO, the problem you're having will happen with any package - there's some 
untoward interaction between the modem and the serial driver.  If the driver is
working, it should be toggling DTR to reset the modem after a session 
completes.
If after this, the modem refuses to respond to 'AT' with 'OK', what package
will go out and power cycle the modem for you? (the ultimate attention 
getter!).

Anyone know who supplies paid technical support for Hylafax?  SUSE says that 
they will, but then one would need to convert from Solaris to Linux...