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] The old "REMOTE HANGUP: No response to EOP repeated 3 times (code 54)" bug again....



On 2003.06.17 02:21 Leif Erlingsson wrote:

> These two logs, the first from a partially failed send
> [see note 1] and the second after changing the single line
> #ModemType:             Class2.0
> ModemType:              Class1
> in the configuration from Class2.0 into Class1,

Typically it is recommended that you just back up your old config file, 
re-run faxaddmodem and choose the new Class type, but what you did 
usually will work with Class 1.

> show that the fax modem may appear to function well in Class 2.0
> (it does with most fax recipients) but with some recipients it
> can't even detect the "remote fax equipment" properly.
> 
> (Note 1:  ~ 10% of fax recipients genereate this error according
> to previous posts on the
>   REMOTE HANGUP: No response to EOP repeated 3 times (code 54)
> bug here on the list)

10% failure rate is MUCH too high.  However, this is not atypical of 
USR's Class 2.0 firmware.  Using USRs in Class 2.0 is not recommended.  
And (I know that I'm prejudiced here...) frankly, Class 1 is simply 
going to work better these days for most users that have modems 
supporting it.

> Could the explanation be -- I am speculating here -- that
> when the OTHER EQUIPMENT _really_ is Class 2.0, _then_ it fails?

The DCE-to-DCE communication (the stuff that goes on over the phone 
lines) does not operate in any "Class" type.  It is a bunch of 
warbling, chirping, pauses, etc. defined by ITU-T.30.  So, even if the 
remote system is a computer with another USR modem operating in Class 
2.0 - we can't tell, because it looks the same to us from here whether 
it operates in Class 2.0 or Class 1.

The DCE-to-DTE communication (the stuff between the computer software 
and the modem) does operate in a "Class" type.  Class 1 is defined by 
ITU-T.31 and Class 2.0/2.1 is defined by ITU-T.32.  These "Class" types 
are essentially a type of language that the modem understands.  Class 1 
operates at a significantly "lower" level, however, and thereby is a 
bit trickier to implement but can allow a great deal of flexibility 
that using Class 2.0 cannot.  The nice thing about Class 2.0 is the 
ease by which a programmer can use it.  The modem manufacturer has 
"built-in" various features into the modem firmware with Class 2.0, and 
the programmers can use these easily without doing that work themselves.

These days the HylaFAX Class 1 code can often outperform most 
manufacturers' Class 2/2.0/2.1 firmware.  The reason you have problems 
in Class 2.0 and not in Class 1 is simply a manifestation (of the 
well-known fact) that the USR Class 2.0 firmware is gravely flawed and 
that HylaFAX's Class 1 code is superior.  Now, back in 1996 this may 
not have been true, but it is true today.

> I.e., if the session is Class 1 anyway, then it works?  But I
> have many successful logs at 14400 bps too, and when running
> Class 1 it seems to settle for 12000 bps....

I've looked at your logs on this and it's hard to tell what's 
happening.  I'd need detailed logs from the remote device to say.  
Chances are good that TCF is failing.


> Or could the REAL PROBLEM be that some recipient Class 1
> equipment is incorrectly treated as Class 2.0 equipment?!

No.  See above.

> Notice how in the Class 2.0 log (I've been running in that mode
> for far too many years), the recipient equipment is detected as
> 
>  ...
> Jun 17 09:54:17.27: [ 2604]: DIAL 6943411$
> Jun 17 09:54:17.27: [ 2604]: <-- [12:ATDT6943411\r]$
> Jun 17 09:54:34.21: [ 2604]: --> [4:+FCO]$
> Jun 17 09:54:37.51: [ 2604]: --> [35:+FNF:^QM-^@M-^JI^PSKM
> HANINGEKONTOSM-^@M-^@M-^@^N^A^A^A^A]$
> Jun 17 09:54:37.51: [ 2604]: REMOTE NSF "^QM-^@M-^JI^PSKM
> HANINGEKONTOSM-^@M-^@M-^@^N^A^A^A^A"$
> Jun 17 09:54:37.51: [ 2604]: NSF remote fax equipment: unknown $

The NSF code should be transmitted to the host in numerical hex values, 
not in ASCII.  This is a flaw of the firmware.

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.*




Project hosted by iFAX Solutions