[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hylafax
Subject:    Re: [hylafax-users] Can send, but can't receive
From:       Lee Howard <faxguy () howardsilvan ! com>
Date:       2003-11-30 3:59:51
[Download RAW message or body]

On 2003.11.29 18:09 Michael Evans wrote:
> I've been experimenting with hylaFAX on and off for a while, trying 
> to get it to work with the following:
> Pentium II, 450 MHz, 128Mb RAM
> SuSE 7.3
> Zoom 2920 PCI modem (Lucent chipset)
> 
> On Nov. 28, I got the latest hylafax sources from CVS and built and 
> installed them.

I use current CVS on a number of production servers with modems in 
Class 1.  I even have a Zoom 2920 on a receive-only line on one of them.

> There's a feature that lets you limit the Class 1 sending and 
> receiving speeds by substituting your own string for the available 
> speeds reported by the modem in response to the AT+FTM=? and AT+FRM=? 
> commands. Once I've limited the modem to 4800 bps, sending works 
> great.

Why do you have troubles with higher speeds?

> However, when the modem's phone number is called, it doesn't seem to 
> get to the speed negotiation part:
> 
> Nov 29 17:23:39.88: [  938]: SESSION BEGIN 00000108 16264494440
> Nov 29 17:23:39.88: [  938]: HylaFAX (tm) Version 4.1.6
> Nov 29 17:23:39.88: [  938]: <-- [4:ATA\r]
> Nov 29 17:23:46.01: [  938]: --> [7:CONNECT]
> Nov 29 17:23:46.01: [  938]: ANSWER: FAX CONNECTION  DEVICE 
> '/dev/ttyS4'
> Nov 29 17:23:46.01: [  938]: MODEM input buffering enabled
> Nov 29 17:23:46.01: [  938]: RECV FAX: begin
> Nov 29 17:23:46.01: [  938]: MODEM input buffering disabled
> Nov 29 17:23:46.01: [  938]: <-- HDLC<32:FF C0 04 AD 00 55 12 9E 36 
> 86 62 82 1A 04 14 2E B6 94 04 6A A6 4E CE 96 F6 76 04 2C 74 8C 74 6C>
> Nov 29 17:23:46.01: [  938]: <-- data [32]
> Nov 29 17:23:46.01: [  938]: <-- data [2]
> Nov 29 17:23:46.02: [  938]: --> [7:CONNECT]
> Nov 29 17:23:46.02: [  938]: <-- HDLC<23:FF C0 02 74 C6 76 92 04 34 
> 16 2E 96 B6 CA 04 64 04 86 EE 86 E6 F6 2A>
> Nov 29 17:23:46.02: [  938]: <-- data [23]
> Nov 29 17:23:46.02: [  938]: <-- data [2]
> Nov 29 17:23:46.02: [  938]: --> [7:CONNECT]
> Nov 29 17:23:46.03: [  938]: <-- HDLC<10:FF C8 01 00 77 5F 01 79 FB 
> C0>

This DIS signal indicates that you are supporting V.27ter, V.29, and 
V.17.  Are you not limiting your receiving speeds?

> Nov 29 17:23:46.03: [  938]: <-- data [10]
> Nov 29 17:23:46.03: [  938]: <-- data [2]
> Nov 29 17:23:48.17: [  938]: --> [2:OK]
> Nov 29 17:23:48.17: [  938]: <-- [9:AT+FRH=3\r]
> Nov 29 17:23:48.27: [  938]: --> [7:CONNECT]
> Nov 29 17:23:49.97: [  938]: --> HDLC<25:FF C0 C2 0C 2C 2C 2C 9C 2C 
> 2C 6C 4C 6C 04 04 04 04 04 04 04 04 04 04 7B D6>
> Nov 29 17:23:49.97: [  938]: --> [2:OK]
> Nov 29 17:23:49.98: [  938]: REMOTE TSI "6264494440"
> Nov 29 17:23:49.98: [  938]: <-- [9:AT+FRH=3\r]
> Nov 29 17:23:49.99: [  938]: --> [7:CONNECT]
> Nov 29 17:23:50.33: [  938]: --> HDLC<11:FF C1 00 45 1F 01 01 01 00 
> CC D3>
> Nov 29 17:23:50.33: [  938]: --> [2:OK]

The modem has a problem.  It should have responded ERROR and not OK 
because the CRC on that frame doesn't check out.  Set 
Class1ValidateV21Frames to "yes" in your modem config file and you will 
see this.  (The modem firmware is supposed to check frames, so the 
software shouldn't have to, but something seems wrong with your modem.)

> Nov 29 17:23:50.33: [  938]: HDLC frame with bad control field 0xc1

A control field is either 0xC0 or 0xC8, so if the previous frame were 
actually valid, then a control field of 0xC1 would be bogus and we 
could point a finger at the remote system.  In this case something's 
wrong with your modem.

> Nov 29 17:23:50.33: [  938]: DELAY 1500 ms
> Nov 29 17:23:51.83: [  938]: <-- [9:AT+FTH=3\r]
> Nov 29 17:23:54.83: [  938]: --> [0:]
> Nov 29 17:23:54.83: [  938]: MODEM TIMEOUT: sending HDLC frame

And your modem seems to be locked at this point and hereforward...

> It always chokes on that one HDLC frame with the "bad control field 
> 0xc1".  It does this regardless of which machine is placing the call 
> (machines calling from different phone numbers).  After "SESSION END" 
> , when the log file is completed, the modem is no longer able to 
> answer any calls.  Any subsequent callers just hear the phone ringing 
> endlessly, with no answer (and no busy signal). If I query the 
> hylafax server with WHFC, it reports "receiving facsimile" instead of 
> the usual "running and idle." The only way to make the modem usable 
> again is to stop hylafax, issue the "faxquit" command, kill the 
> faxgetty process, and then restart hylafax.

Exactly... your modem seems to have become unresponsive.

> Meanwhile, depending on his machine, the sender gets a "NG - Poor 
> Line Condition" error message or something similar, and his machine 
> hangs up.

I wouldn't put too much faith in this diagnostic.  But, to your 
knowledge are the line conditions poor?

> In searching through the message logs, I got a hint that this might 
> be due to an outdated libtiff (I had v. 3.4), so I went to 
> libtiff.org and got the latest version, v 3.6. But building and 
> installing the latest version over the old one didn't help.

libtiff has nothing to do with this.

I would venture to guess that either you are having modem hardware 
failures, something is wrong with the kernel serial driver on your 
system, or some other hardware or software is interfering with the 
modem (i.e., bad motherboard, etc.).

The easiest thing to do may be to try another modem on one of the 
external serial ports (provided that you have an external serial modem 
to use).

Lee.

____________________ 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@hylafax.org < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*

[prev in list] [next in list] [prev in thread] [next in thread]