Subject: Re: [netatalk-admins] toner low errors
From: Andras Kadinger (bandit@freeside.elte.hu)
Date: Sat Aug 15 1998 - 22:59:10 EDT
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:
Darren Atkinson wrote:
> 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
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.
> I recompiled pap with its debugging messages and also hacked the code
> a little bit to ignore the error.
Hmm, what error do You ignore?
> But now I get this:
>
> murdoch % ./pap -p paanini /usr/lib/atalk/pagecount.ps
> Trying 3841.134:157 ...
> OPEN >
> < OPENREPLY
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,
> SENDSTATUS >
> < 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
> 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 ];
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?
> 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?
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
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:05 EST