HylaFAX The world's most advanced open source fax server

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

Re: [hylafax-users] Problems debugging serial ports (internal and SIIG)



I think this issue is closed. Andrew was correct, I needed to follow all of the physical lines as well as configurations. 

This is what was going on in my environment. Unbeknownst to me, the telco line I was using to test was connected to a fax machine. The modem and machine must have attempted to answer calls and the machine always won. Removing the line on the fax machine allowed the modem to do its job. So far so good. 

Thanks for your assistance. 

Mark

>>> Mark Gillingham 1/4/2006 3:52:23 PM >>>
Thanks to Andrew Rinaldi, I had a tidy list to check today that included cables, comm parameters, and config files. None of my tests made a difference including switching modems and putting both receiving modems on the motherboard (ttyS0 and ttyS1). I also tried class 1 (the modem that works is configured for class 2.0 with help from this list). 
 
A typical session between a fax machine and my fax modem on ttyS0 follows. Remember, if I fax from ttyS3 to ttyS0 or from ttyS1 to ttyS0, I receive faxes OK, which makes me think there is a configuration issue. From the information I gleaned from the list, I should try Class 1 again. What Class 1 gotchas are there with the Courier V-Everything? 
 
Once again, thanks for you help. /mark 
 
Jan 04 15:17:56.47: [ 2981]: SESSION BEGIN 000001083 12345678901 
Jan 04 15:17:56.47: [ 2981]: HylaFAX (tm) Version 4.2.1 
Jan 04 15:17:56.47: [ 2981]: <-- [4:ATA\r] 
Jan 04 15:18:03.10: [ 2981]: --> [4:+FCO] 
Jan 04 15:18:03.10: [ 2981]: ANSWER: FAX CONNECTION  DEVICE '/dev/ttyS0' 
Jan 04 15:18:03.10: [ 2981]: RECV FAX: begin 
Jan 04 15:18:05.27: [ 2981]: --> [27:+FCI:         +1234567890] 
Jan 04 15:18:05.73: [ 2981]: --> [20:+FIS:1,5,0,2,1,0,0,1] 
Jan 04 15:18:08.62: [ 2981]: --> [20:+FCS:0,5,0,2,0,0,0,0] 
Jan 04 15:18:08.62: [ 2981]: REMOTE wants 14400 bit/s 
Jan 04 15:18:08.62: [ 2981]: REMOTE wants A4 page width (215 mm) 
Jan 04 15:18:08.62: [ 2981]: REMOTE wants unlimited page length 
Jan 04 15:18:08.62: [ 2981]: REMOTE wants 3.85 line/mm 
Jan 04 15:18:08.62: [ 2981]: REMOTE wants 1-D MH 
Jan 04 15:18:11.32: [ 2981]: --> [7:+FHS:71] 
Jan 04 15:18:11.32: [ 2981]: REMOTE HANGUP: RSPREC error/got DCN (code 71) 
Jan 04 15:18:11.32: [ 2981]: --> [2:OK] 
Jan 04 15:18:11.32: [ 2981]: RECV FAX: RSPREC error/got DCN 
Jan 04 15:18:11.32: [ 2981]: RECV FAX: end 
Jan 04 15:18:11.32: [ 2981]: SESSION END 
 
<--config.ttyS0 --> 
LongDistancePrefix:     1 
InternationalPrefix:    011 
DialStringRules:        etc/dialrules 
ServerTracing:          1 
SessionTracing:         11 
RecvFileMode:           0644 
LogFileMode:            0644 
DeviceMode:             0666 
RingsBeforeAnswer:      1 
SpeakerVolume:          off 
GettyArgs:              -h %l dx_%s 
LocalIdentifier:        GBF0224 
TagLineFont:            etc/lutRS18.pcf 
MaxConsecutiveBadLines:       0               # don't check (default is 5) 
PercentGoodLines:     0               # don't check (default is 95%) 
TagLineFormat:          From %%l|%c|Page %%P of %%T 
PercentGoodLines:       0 
MaxConsecutiveBadLines: 0 
MaxRecvPages:           99 
ModemPriority:                255     # Don't encourage outbound faxing 
ModemReadyState:      D                       # getty will think it's down 
Modem:                        inbound 
# 
# 
# Modem-related stuff: should reflect modem command interface 
# and hardware connection/cabling (e.g. flow control). 
# 
ModemType:              Class2.0        # use class 2.0 interface 
ModemRate:              19200           # DCE-DTE communication rate 
ModemFlowControl:       rtscts          # hardware flow control 
# 
ModemNoFlowCmd:         AT&H0&I0&R1     # setup modem for no flow control 
ModemHardFlowCmd:       AT&H1&I0&R2     # setup modem for hardware flow control 
ModemSoftFlowCmd:       AT&H2&I2&R1     # setup modem for software flow control 
# 
ModemSetupDTRCmd:       ATS13=1&D2      # setup so DTR drop resets modem 
ModemSetupDCDCmd:       AT&C1           # setup so DCD reflects carrier (or not) 
#ModemResultCodesCmd:   ATQ0X4          # enable extended result codes 
ModemResultCodesCmd:  ATQ0X3          # enable extended result codes 
# 
# NB: adaptive answer only seems to work properly when 
#     the modem is left idling in Class 2.0 
# 
ModemSetupAACmd:        AT+FAA=1 
# 
# Set modem speaker volume commands: OFF QUIET LOW MEDIUM HIGH. 
# Note that we both turn the speaker on/off and set volume. 
# 
ModemSetVolumeCmd:      ATM0 ATM1 ATM1 ATM1 ATM1 
# 
# Modem does not support HDLC frame tracing; we add this just 
# to eliminate spurious ERROR results that confuse the naive. 
# 
#Class2BUGCmd:          AT+FBU=0 
# 
# The modem doesn't support copy quality checking, even though it 
# returns (0-2,0-2) for AT+FCQ=?; therefore we override the query 
# response so that the server will do copy quality checking. 
# 
Class2CQQueryCmd:       !(0),(0)        # override modem response 
# 
# Disables the reporting of bad frames by the modem.  This 
# overcomes a firmware problem in the x2 and V90 Sportsters. 
# to eliminate spurious ERROR results that confuse the naive. 
# 
#Class2BUGCmd:          AT+FBU=0 
# 
# The modem doesn't support copy quality checking, even though it 
# returns (0-2,0-2) for AT+FCQ=?; therefore we override the query 
# response so that the server will do copy quality checking. 
# 
Class2CQQueryCmd:       !(0),(0)        # override modem response 
# 
# Disables the reporting of bad frames by the modem.  This 
# overcomes a firmware problem in the x2 and V90 Sportsters. 
# It is not necessary for the Courier modem. 
# 
Class2NRCmd:    AT+FNR=1,1,1,0 
# 
# USR modems violate Class 2.0 specs and do not send RTC itself 
# 
Class2SendRTC:  yes 
# 
# +FAP=? not supported on this modem, gives ERROR in ServerTracing 
# 
Class2APQueryCmd:       none 
 
 
 
>>>Mark Gillingham <Mark.Gillingham@xxxxxxxxxxxxxx> 01/03/06 4:59 pm >>> 
 
Our setup has three identical Courier V-everything modems. We have been using just one of them for reception for 2 years with little problem. This one is on ttyS1, a motherboard serial port. Recently, we needed to add a second reception line (and we've reduced sending) so I configured an identical modem with the same configuration as ttyS1, but this modem is on a PCI serial card (by SIIG), which we've used successfully for sending. Now the setup is like this: 
 
 
ttyS1 <- receive-motherboard 
 
ttyS2 <- receive-PCI 
 
ttyS3 -> send-PCI 
 
 
When testing ttyS2 by using the sending modem on ttyS3, I get good reception results. Most other receptions fail in various ways (I've swapped the modems on ttyS2 and ttyS3). I've kept a list. It dawned on me that the main difference between ttyS1 and ttyS2 is the serial port. It may be that sending from ttyS3 to ttyS2 works because it is from-to the same PCI serial card. If that is the case, I need to do some testing, but I don't know where to begin. Can I test with Hylafax tools? Am I way off base? 
 
 
Mark 
 
 
 
____________________ HylaFAX(tm) Users Mailing List 
 
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi 
 
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null 
 
 *To learn about commercial HylaFAX(tm) support, mail 
 

____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*




Project hosted by iFAX Solutions