Re: flexfax: Weird Phase B Error (with solution)

[Richard Kail <e8903122@student.tuwien.ac.at>]

Hello !

On Sun, 11 Apr 1999, David Woolley wrote:

> I'm rather reluctantly replying to this, given your failure to subscribe to
> the list...

Look, I was two years subscribed on the mailinglist and unsubscribed some
weeks ago. As you know, murpheys law....


> Diagnosing Transmit Phase B errors (which are the most common ones)
> requires the session logs.

I will attach examples at the end of the mail.

> > the output for WHFC. This postscript files start with
> > 
> > ESC%-12345X@PJL
> > @PJL ENTER LANGUAGE = POSTSCRIPT
> > %!PS-Adobe-3.0
> 
> These are not Postscript files, they are Xerox printer files.  A Postscript
> file would start on the third line.

These are not postscript files, sure. But what you see here is a PJL
Header to switch the printer to postscript mode. Several postscript
printer drivers do it this way, so I think it wouldn't be the badest idea
to handle this. The PJL Header is defined and documented in the HP Printer
Job Language Technical Reference Manual. Ghostscript can handle this
kind of headers without any problem.
 
I thought that I can handle this with a typerule and a small filter - but
as I described .... Nope.

> The proper fix is to use a sensible Postscript printer driver for your
> fax printer.  There are some on Windows.  (If anyone has access to the right
> documentation and tools, and the time to do it, it might be an idea to
> create a hylafax/ghostscript printer driver for Windows - probably just
> changing the names on one of the common ones.)

I know this and I know the printer drivers (the old Apple Drivers for
example). But however, there may be reasons to use other drivers. For
example, some Apple Postscript Drivers delivered with NTWS4.0 can get into
a state where gs can't handle the postscript produced. Unfortunately, I
lost the sampe of this. The advantage of the Xerox drivers, for example,
is that the postscript produced is very readable.

> That is fairly clearly documented - TIFF and PS are the only formats 
> supported by the server; the client must convert to one of these before
> submission.

This is ok - but I am unhappy about this. Converting documents to Tiff or
PS is what unix tools can do very well. On other client plattforms doing
this is not nice at all. There is also the problem that it is easier to
manage one set of converter tools on the server that to manage them on
zillions of clients.

Therefor it would be very very handy to let the server convert the files
also. Implement such a feature doesn't hinder you to convert at the client
- it is just a option.

> > - The error message "Unspecified Transmit Phase B error" is very
> > misleading. Maybe there is a way to fix this.
> 
> It's really rather difficult to diagnose without the logs, but it 
> really is a case of garbage in garbage out.
> 
> > - Creating a "all ok"-notification with this error is not ok. 
> 
> Again diagnosing this requires the logs.
> 
> Note my experience of doing this with a beta version was that you simply
> got an empty fax.


Apr 11 14:56:29.09: [  589]: SESSION BEGIN 00000003 431713590915
Apr 11 14:56:29.09: [  589]: SEND FAX: JOB 17 DEST 713590915 COMMID
00000003
Apr 11 14:56:29.10: [  589]: DELAY 2600 ms
Apr 11 14:56:31.69: [  589]: <-- [16:ATX2E0V1Q0S0=0H\r]
Apr 11 14:56:31.73: [  589]: --> [2:OK]
Apr 11 14:56:31.73: [  589]: <-- [21:ATS8=2S7=60\Q3&D2&C1\r]
Apr 11 14:56:31.77: [  589]: --> [2:OK]
Apr 11 14:56:31.77: [  589]: <-- [14:AT+FCLASS=2.0\r]
Apr 11 14:56:31.81: [  589]: --> [2:OK]
Apr 11 14:56:31.81: [  589]: <-- [9:AT+FLO=2\r]
Apr 11 14:56:31.84: [  589]: --> [2:OK]
Apr 11 14:56:31.84: [  589]: <-- [9:AT+FPP=0\r]
Apr 11 14:56:31.87: [  589]: --> [2:OK]
Apr 11 14:56:31.87: [  589]: <-- [9:AT+FBO=0\r]
Apr 11 14:56:31.90: [  589]: --> [2:OK]
Apr 11 14:56:31.90: [  589]: <-- [10:AT+FCT=30\r]
Apr 11 14:56:31.93: [  589]: --> [2:OK]
Apr 11 14:56:31.93: [  589]: <-- [15:AT+FNR=1,1,1,1\r]
Apr 11 14:56:31.97: [  589]: --> [2:OK]
Apr 11 14:56:31.97: [  589]: <-- [7:AT+FAP\r]
Apr 11 14:56:32.00: [  589]: --> [5:ERROR]
Apr 11 14:56:32.00: [  589]: MODEM Command error
Apr 11 14:56:32.00: [  589]: <-- [9:AT+FIE=0\r]
Apr 11 14:56:32.03: [  589]: --> [2:OK]
Apr 11 14:56:32.03: [  589]: <-- [23:AT+FCC=1,5,2,2,0,0,0,0\r]
Apr 11 14:56:32.07: [  589]: --> [2:OK]
Apr 11 14:56:32.07: [  589]: <-- [7:ATL3M1\r]
Apr 11 14:56:32.10: [  589]: --> [2:OK]
Apr 11 14:56:32.10: [  589]: <-- [14:AT+FCLASS=2.0\r]
Apr 11 14:56:32.24: [  589]: --> [2:OK]
Apr 11 14:56:32.24: [  589]: <-- [9:AT+FLO=2\r]
Apr 11 14:56:32.37: [  589]: --> [2:OK]
Apr 11 14:56:32.37: [  589]: <-- [9:AT+FPP=0\r]
Apr 11 14:56:32.50: [  589]: --> [2:OK]
Apr 11 14:56:32.50: [  589]: <-- [9:AT+FBO=0\r]
Apr 11 14:56:32.63: [  589]: --> [2:OK]
Apr 11 14:56:32.63: [  589]: <-- [10:AT+FCT=30\r]
Apr 11 14:56:32.76: [  589]: --> [2:OK]
Apr 11 14:56:32.76: [  589]: <-- [15:AT+FNR=1,1,1,1\r]
Apr 11 14:56:32.90: [  589]: --> [2:OK]
Apr 11 14:56:32.90: [  589]: <-- [7:AT+FAP\r]
Apr 11 14:56:33.03: [  589]: --> [5:ERROR]
Apr 11 14:56:33.03: [  589]: MODEM Command error
Apr 11 14:56:33.03: [  589]: <-- [9:AT+FIE=0\r]
Apr 11 14:56:33.16: [  589]: --> [2:OK]
Apr 11 14:56:33.16: [  589]: <-- [23:AT+FCC=1,5,2,2,0,0,0,0\r]
Apr 11 14:56:33.30: [  589]: --> [2:OK]
Apr 11 14:56:33.30: [  589]: <-- [26:AT+FLI="Petromontan Enns"\r]
Apr 11 14:56:33.44: [  589]: --> [2:OK]
Apr 11 14:56:33.44: [  589]: DIAL 713590915
Apr 11 14:56:33.44: [  589]: <-- [15:ATDT713590915@\r]
Apr 11 14:57:09.46: [  589]: --> [4:+FCO]
Apr 11 14:57:12.24: [  589]: --> [27:+FCI:"      00431713590915"]
Apr 11 14:57:12.24: [  589]: REMOTE CSI "00431713590915"
Apr 11 14:57:12.24: [  589]: --> [20:+FIS:1,3,0,2,1,1,0,5]
Apr 11 14:57:12.24: [  589]: --> [2:OK]
Apr 11 14:57:12.24: [  589]: REMOTE best rate 9600 bit/s
Apr 11 14:57:12.24: [  589]: REMOTE max page width 1728 pixels in 215 mm
Apr 11 14:57:12.24: [  589]: REMOTE max unlimited page length 
Apr 11 14:57:12.24: [  589]: REMOTE best vres 7.7 line/mm
Apr 11 14:57:12.24: [  589]: REMOTE best format 2-D MR
Apr 11 14:57:12.24: [  589]: REMOTE supports T.30 Annex A, ECM
Apr 11 14:57:12.24: [  589]: REMOTE best 20 ms/scanline
Apr 11 14:57:12.24: [  589]: USE 9600 bit/s
Apr 11 14:57:12.24: [  589]: USE 20 ms/scanline
Apr 11 14:57:12.24: [  589]: <-- [4:ATH\r]
Apr 11 14:57:13.83: [  589]: --> [7:+FHS:20]
Apr 11 14:57:13.83: [  589]: REMOTE HANGUP: Unspecified Transmit Phase B
error (code 20)
Apr 11 14:57:13.83: [  589]: --> [2:OK]
Apr 11 14:57:13.83: [  589]: SESSION END


The user gets a email:


>From fax@pmserv.petromontan.at  Sun Apr 11 14:57:14 1999
Return-Path: <fax>
Received: (from uucp@localhost)
        by pmserv.petromontan.at (8.8.8/8.8.8) id OAA00614;
        Sun, 11 Apr 1999 14:57:13 +0200
Date: Sun, 11 Apr 1999 14:57:13 +0200
From: Facsimile Agent <fax@pmserv.petromontan.at>
Message-Id: <199904111257.OAA00614@pmserv.petromontan.at>
To: ntadm@pmserv.petromontan.at
Subject: facsimile job 17 to 713590915 completed

Your facsimile job to 713590915 was completed successfully.

         Pages: 0
       Quality: Normal
    Page Width: 194 (mm)
   Page Length: 281 (mm)
   Signal Rate: 9600 bit/s
   Data Format: 2-D MMR
Submitted From: pm-ws1
         JobID: 17
       GroupID: 17
        CommID: c00000003

Processing time was 0:50.



the first couple of lines of the document file:

ESC%-12345X@PJL
@PJL ENTER LANGUAGE = POSTSCRIPT
%!PS-Adobe-3.0
%%Title: Microsoft Word - Testfax.doc
%%Creator: Windows NT 4.0
%%CreationDate: 14:56 4/11/1999
%%Pages: (atend)
%%BoundingBox: 14 12 581 829
%%LanguageLevel: 2
%%DocumentNeededFonts: (atend)
%%DocumentSuppliedFonts: (atend)
%%EndComments
%%BeginProlog

%%BeginResource: procset NTPSOct95


GNU Ghostscript 5.10 (1998-12-17) is processing the file without any
problems.

The q17-File in doneq looks like

tts:923835433
killtime:923838983
retrytime:0
state:7
npages:0
totpages:0
ntries:0
ndials:0
totdials:1
maxdials:12
tottries:1
maxtries:3
pagewidth:194
resolution:98
pagelength:281
priority:127
schedpri:127
minsp:0
desiredbr:5
desiredst:0
desiredec:1
desireddf:3
desiredtl:0
useccover:1
external:713590915
number:713590915
mailaddr:ntadm
sender:Richard Kail (ADM)
jobid:17
jobtag:
pagehandling:
modem:any
receiver:
company:
location:
cover:
client:pm-ws1
owner:ntadm
groupid:17
signalrate:9600 bit/s
dataformat:2-D MMR
jobtype:facsimile
tagline:
subaddr:
passwd:
doneop:default
commid:00000003
status:
notify:when done+requeued
pagechop:default
chopthreshold:3
data:0::docq/doc2.ps.17


Ok, what I think/suggest:

The fact that the user gets a "all things worked" notification while
nothing was transmitted worries me. I think we should find a fix for this,
regardless what the documentation says.

The second point - related with the first is the typechecking on the
server side.

HylaFAXServer::docType(const char* docname, FaxSendOp& op)
{
    op = FaxRequest::send_unknown;
    int fd = Sys::open(docname, O_RDONLY);
    if (fd >= 0) {
        struct stat sb;
        if (FileCache::lookup(docname, sb) && S_ISREG(sb.st_mode)) {
            union {
                char buf[512];
                TIFFHeader h;
            } b;
            int cc = Sys::read(fd, (char*) &b, sizeof (b));
            if (cc > 2 && b.buf[0] == '%' && b.buf[1] == '!')
                op = FaxRequest::send_postscript;
            else if (cc > sizeof (b.h) && isTIFF(b.h))
                op = FaxRequest::send_tiff;
            else
                op = FaxRequest::send_data;
        }
        Sys::close(fd);
    }
    return (op != FaxRequest::send_unknown);   
}

If hfaxd can't recognice Postscript or Tiff data, it flags the Request
with send_data, which is passed happily to faxsend as it is. I don't think
that it is paranoid to do some additional checks (wherever) to prevent
junk data to be passed to faxsend. 

One way would be to reject the file here, so that it would bail out here
in hfaxd:

fxBool
HylaFAXServer::checkAddDocument(Job& job, Token type,
    const char* docname, FaxSendOp& op)
{
    if (checkParm(job, type, A_WRITE)) {
        struct stat sb;
        if (!fileAccess(docname, R_OK, sb))
            perror_reply(550, docname, errno);
        else if (!docType(docname, op))
            reply(550, "%s: Document type not recognized.", docname);
        else
            return (TRUE);
    }
    return (FALSE);
}

I don't know what the send_data modus is used for, so this may be the
right thing to do. My problem could be solved this way. (Maybe this breaks
the IXO/TAP pagesend stuff ?)

Another way would be to do some checking in faxq if the data to send is
something useful. The ultimative solution - for my case - would be to
reuse the typechecking/document-preparation-code of sendfax in faxq. If we
convert postscript files out of faxq, why shouldn't we convert other file
types also ?

Kind regards,
	Richard

------
The world is a jungle in general, and the networking game
contributes many animals. ---- David C. Plummer, RFC 826