Subject: Re: [netatalk-admins] toner low errors
From: Darren Atkinson (atkinson@cs.ucsd.edu)
Date: Mon Aug 17 1998 - 13:28:00 EDT
Andras,
The result is coming back as 0xffff (-1 as a signed short). My hack
to the code is below. But, here's a strange thing. I just tried
connecting to the printer using pap and it worked for a while. This
is with the non-hacked version of pap:
murdoch % pap -E -p paanini /usr/lib/atalk/pagecount.ps
Trying 3841.134:157 ...
status: PrinterError: toner is low; source: AppleTalk
Connected to paanini:LaserWriter@CSE.
Connection closed.
murdoch % pap -p paanini /usr/lib/atalk/pagecount.ps
Trying 3841.134:157 ...
status: warming up; source: AppleTalk
Connected to paanini:LaserWriter@CSE.
*35121
Connection closed.
murdoch % pap -p paanini /usr/lib/atalk/pagecount.ps
Trying 3841.134:157 ...
status: PrinterError: toner is low; source: AppleTalk
Connected to paanini:LaserWriter@CSE.
*35121
Connection closed.
murdoch % pap -w -p paanini /usr/lib/atalk/pagecount.ps
Trying 3841.134:157 ...
status: PrinterError: toner is low; source: AppleTalk
Connected to paanini:LaserWriter@CSE.
murdoch % 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
I tried pap with -E as suggested, and the job didn't hang, but I
didn't get the pagecount back either. After that, pap worked fine
until I ran it with -w and it just waited. I expected that behavior
since "toner is low" doesn't match "waiting". So, I interrupted pap
and after that I started getting the problem again.
The behavior after I interrupted pap is what you mentioned. However,
I waited several minutes before trying to connect to the printer again
hoping the connection would time out, but it hasn't so far. Oops, let
me take that back. After waiting about 15 minutes, I can talk to the
printer again.
I've seen similar problems with HP printers when talking to them via
TCP/IP. If the client is terminated and doesn't close the socket, the
printer is pretty much hung until power cycled.
So, what can we learn from this behavior? I mean besides the fact
that HP printers aren't the easiest things in the world to talk to.
Here's my current scenario of what was happening:
I need to use -w to get accurate page counts. But, with -w the
printer status "toner is low" won't match "waiting", so pap just sits
there waiting. So, I remove the job using lprm or just interrupt pap
if I'm just running it from the command line. But then pap is
terminated without closing down the connection. As a result, the
connection is hung and you have to wait for it to timeout before
trying again.
Possible fixes? If you don't need to use -w, then don't. If pap is
never interrupted, then things seem to work fine. Of course, if you
cancel the active print job then you may run into problems with hung
connections.
If you need to use -w to do accurate accounting, then we need to do
some work it seems. First, add some signal handlers to pap so that it
properly closes down the connection. Second, reverse or otherwise
change the logic in pap so that instead of checking if the status
contains "waiting", it makes sure the status doesn't say "busy" or
"printing". Does this sound plausible?
Thanks again for all your help!
Darren
----------------------------------------------------------------------
if ( result != 0 ) {
{
char big_buf [16384];
strncpy (big_buf, iov.iov_base + 9, iov.iov_len - 9);
if (strstr (big_buf, "toner is low")) {
printf ("ignoring error\n");
bcopy( &nn.nn_sat, &sat, sizeof( struct sockaddr_at ));
quantum = rbuf[ 5 ];
break;
}
}
sleep( 2 );
} else {
bcopy( &nn.nn_sat, &sat, sizeof( struct sockaddr_at ));
sat.sat_port = rbuf[ 4 ];
quantum = rbuf[ 5 ];
break;
}
In the code above, rbuf[4] is always 0, which is why I'm not setting
sat.sat_port to rbuf [4]. I looked and sat.sat_port does contain a
value but I guess it isn't the right value to talk to the printer and
you need to extract the right port number from the reply packet.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:08 EST