Subject: Re: [netatalk-admins] toner low errors

From: Darren Atkinson <[email-masked]>
Date: Sat, 15 Aug 1998 16:45:06 -0700 (PDT)

I thank Wesley and Andras for their responses, but unfortunately they
didn't fix the problem.  My first thought was that I was using the -w
flag to pap (from psf) and that the string "Printer Error: toner is
low" certainly doesn't match "waiting".  But, even when I just use pap
by itself without the -w flag, I still experience the same problem:

murdoch % /usr/bin/pap -p paanini /usr/lib/atalk/pagecount.ps 
Trying 3841.134:157 ...
status: PrinterError: toner is low; source: AppleTalk
status: PrinterError: toner is low; source: AppleTalk
status: PrinterError: toner is low; source: AppleTalk
status: PrinterError: toner is low; source: AppleTalk
status: PrinterError: toner is low; source: AppleTalk

I recompiled pap with its debugging messages and also hacked the code
a little bit to ignore the error.  But now I get this:

murdoch % ./pap -p paanini /usr/lib/atalk/pagecount.ps
Trying 3841.134:157 ...
OPEN >
< OPENREPLY
status: PrinterError: toner is low; source: AppleTalk
ignoring error  <<< my comment
Connected to paanini:LaserWriter@CSE.
READ 1 >
SENDSTATUS >
< STATUS
TICKLE >

The connection eventually times out.  I don't think I just blindly
ignore the failed open reply.  If you look at the code, the port
number seems to be extracted from the reply:

            bcopy( &nn.nn_sat, &sat, sizeof( struct sockaddr_at ));
>>>>        sat.sat_port = rbuf[ 4 ];
            quantum = rbuf[ 5 ];

The printer is set for "LOW TONER = CONT" so that can't be the
problem.  As a matter of fact, we've bought some defective toner
cartridges that work just fine using TCP/IP except the printer always
says "LOW TONER".

What I'm thinking is that this is probably a another bug in HP's PAP
implementation.  If "LOW TONER = STOP" then yes, the open should fail.
But, if "LOW TONER = CONT", then the open should succeed.  So, I guess
I really need yet another kludge to be added to pap/psf to work around
this problem.  Is there any way to open the connection and ignore the
error?

Thanks,
Darren

----------------------------------------------------------------------
In reply to the following message:

>From [email-masked]  Sat Aug 15 08:34:39 1998
Date: Sat, 15 Aug 1998 17:34:34 +0200 (CEST)
From: Kadinger Andras <[email-masked]>
To: Darren Atkinson <[email-masked]>
Subject: Re: [netatalk-admins] toner low errors

Hi Darren,

I've just spent an hour exploring the various media handling options an
option menus of our 4MV, and I stumbled across an option in the front
panel: CONFIG | LOW TONER should be set to CONT to make the printer
continue printing (vs. STOP, where it doesn't allow further printing).

Of course, Wesley is also right regarding the '-w' parameter.

Hope, this helps,

Sincerely,
Andras Kadinger
[email-masked]

---

From: Andras Kadinger <[email-masked]>
Date: Sun, 16 Aug 1998 04:59:10 +0200

Darren,

Another kind that came to my mind regarding my dislikes about pap was,
that if pap gets interrupted (^C, kill, etc.), it doesn't send the
PAP_CLOSE message to the other end, causing the other end to 'stuck' and
only release the connection after the 120sec PAP timeout. The pap
messages below:

> status: PrinterError: toner is low; source: AppleTalk

don't say anything about being connected, so I guess, pap gets a
'printer is busy' reply and retries in every 2 seconds as per PAP.

> a little bit to ignore the error.

Hmm, what error do You ignore?

> But now I get this:

This is done so in every PAP connection; only the OPENREPLY contains
busy, when the printer won't accept data on the connection. Might You
ignore this?

> status: PrinterError: toner is low; source: AppleTalk

This is normal; pap updates and writes the status from the OPENREPLY.

> ignoring error  <<< my comment

??? - I guess You ignore the busy indication here.

> Connected to paanini:LaserWriter@CSE.

I'm not sure You really are...

> READ 1 >

Sent, but no response,

> < STATUS

SendStatus does not get to the actual PAP client 'process', but the PAP
stack handles it directly - this is why You can get status without
actually connecting.

> TICKLE >

Since nothing happened - You sent Your requests, and received nothing -
a 'tickle' must be sent to indicate, the connection is not dead. But You
still receive nothing, so

> The connection eventually times out.

correctly, in my opinion.

> I don't think I just blindly ignore the failed open reply.

Hmm, I not sure. It looks suspiciously similar to as if You did...

>  If you look at the code, the port

right _after_ the check of
	if ( result != 0 ) {

Are You sure it gets executed? Try printing out result before the if. If
it's 0xffff the printer is busy, if it's 0, it's not. I sincerely hope,
it's not having another, third value...

[later...]

Hmm, strange. I might be new to ATP and PAP, but I don't understand, why
only the PAP_TICKLE and PAP_SENDSTATUS gets sent through the 'satp'
handle (with the newly acquired port number as You pointed out), and
everything else through the 'atp' one? Do You know the reason? Or is
this a bug?

> this problem.  Is there any way to open the connection and ignore the

I am still not sure what do You mean by error here. But if the server
rejects Your OPEN with an OPENREPLY containing busy indication, I would
expect something very close to what You report above - to ignore any
further requests sent on that connection.

Sincerely,
Andras Kadinger
[email-masked]

---

From: Andy Clay <[email-masked]>
Date: Sun, 16 Aug 1998 21:25:59 +1000

Hi all I have a problem with printing from macs to Linux server.  The
setup is

Slackware 3.5, Kernel 2.0.35
Netatalk 1.4b2
TI microwriter PS23 printer. 
MAC LC475, System 7.6.1, Laserwriter 8
MAC 7220, System 8.1, Laserwriter 8

The problem is that small jobs ( up to about 4 pages of text) print OK
if sent 1 or 2 at a time. If you queue say 10 prints of a window, then
some get printed (3-5), and the rest of the prints get dropped on the
floor.  You can see them going from the spool dir, and the printer data
led flashes, then just stops without printing any more pages.  Does
anyone know what might cause this problem, or point me in the right
direction to solve it?.

If you need more info, please mail me.

Cheers.... Andy.

---

From: Andras Kadinger <[email-masked]>
Date: Sun, 16 Aug 1998 14:49:14 +0200

Andy,

> anyone know what might cause this problem, or point me in the right

Your problems most probably are caused by papd, which corrupts binary
PostScript streams depending on the content. When the corrupted stream
gets sent to the printer, the printer has no other way of 'cancelling'
the job after the corruption is detected, than consuming the rest of the
job. On the other hand, if printing ten times the _exact_ same PS stream
fails in some cases, but succeeds in others, that is something worth
looking into.

Fixing papd is in the works; for the time being I'm afraid You have no
other options (unless You can participate in the fixing), than to avoid
sending binary PostScript through papd; use ASCII or try to print to a
file on the server instead, and send that with pap if You can - I know,
this is not an acceptable solution is some cases.

Sincerely,
Andras Kadinger
[email-masked]

---

From: Bill Studenmund <[email-masked]>
Date: Sun, 16 Aug 1998 17:58:32 -0700 (PDT)

> by itself without the -w flag, I still experience the same problem:

[details snipped]

> this problem.  Is there any way to open the connection and ignore the

Antoher option is to fire up a packet sniffer. Watch a Mac print to this
printer, and see what happens. As the LaserWriter driver gets this right
when talking to our HP printer, I think there's a standard way to deal
with this error. 

Take care,

Bill

---

From: Andras Kadinger <[email-masked]>
Date: Mon, 17 Aug 1998 15:12:52 +0200

Hannu Krosing wrote:
> 
> Andras Kadinger wrote:
> >
> >
> > Fixing papd is in the works;
> 
> Do you have some more info about this: what exactly is wrong and who
> is working fixing it.

Currently is seems, that papd cannot properly handle binary postscript
streams; symptoms are excess CPU usage, corruption of the spooled data,
sometimes papd hangs; some people reported they can not spool jobs
beyond a certain size, which later was suggested to be the size of their
virtual memory.

Wesley Craig wrote:
> The latest theory (from [email-masked]) is that this is a
> binary postscript problem.  The 256M limit on your machine is your
> virtual memory.  He has eliminated the problem with a heuristic that
> causes partial lines to be written, in the event of lines over some
> maximum with good results.  I think a general solution would include
> implementing binary transmission in papd.

In the meantime, I am also crawling the source code of pap and papd and
will try to make them a bit more reliable and implement binary support,
and will look into creating support for lprng which was sought after on
the list before. (Anyone with pointers to lprng please email them to me,
if you can.)

Is anybody else working on these issues?

> I have currently problems with printing from Quark Xpress4.0, and it
> seems like the same problem

To test this, you might want to try to circumvent papd by writing the
PostScript data directly to a file and use that in the next step (lpr, I
guess). Also, there were a couple of printing problems in different
versions of QX4.0; check www.quark.com for updates.

Sincerely,
Andras Kadinger
[email-masked]

---

From: [email-masked]
Date: Mon, 17 Aug 1998 14:09:17 -0400

> From:    Andras Kadinger <[email-masked]>

> everything else through the 'atp' one? Do You know the reason? Or is

The status is out-of-band.  There is no provision to get status on the
"server responding" socket.  Hence, a new ATP handle is made and used
to get the status from the NBP registered address.

No requests are required to be from the "client responding" socket.
However, since PAP only allows a single outstanding read request, we
use the same ATP handle (atp) for responding and reading.  We send the
tickles with a different ATP handle (satp) since the ATP library can't
handle two simultaneous outstanding requests.

:wes