Red Hat Bugzilla – Bug 323311
Get-Job-Attributes returning job not found error should result in cups marking job complete
Last modified: 2007-11-30 17:12:17 EST
Description of problem:
There are certain "IPP" print servers out there (the guilty will remain
anonymous if they fix the problem) that forget a job as soon as it is completed.
This results in cups stalling "waiting for job to complete..." when printing to
them. Cups should be patched to accept a "job not found" as complete. This is
because the standard defines no minimum time a job id must remain valid after
completion and many foolish people are thinking this means forgetting it
immediately is great and acceptable.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get a black box ipp server
2. Print to it from cups via ipp
3. Watch cups stall indefinitely (or until you do some black magic on the black box)
"Waiting for job to complete..."
Job is finished and cups recognizes it.
It already does this:
if (ipp_status == IPP_NOT_FOUND)
* Job has gone away and/or the server has no job history...
ipp_status = IPP_OK;
Are you able to attach a tcpdump/ethereal trace of the IPP request? Something
like this will do:
tcpdump -s0 -U -w ipp.pcap tcp port ipp
I will be able to provide this later this evening (+8 hours or so from now).
My apologies for the delay. I was very occupied with the manufacturer of the
device yesterday and just finished it. It was a repackage of another device and
the original manufacturer has EOLed the product. Hence, innocent and decent, but
unable to help.
Attached is the IPP trace as requested. Sent to an Epson C88 through the device
by CUPS on F8test3 (rawhide current) on behalf of a Windows Postscript driver.
Created attachment 223251 [details]
The capture bziped
Okay, I think this is the queue you're printing to:
This proceeds as follows:
> Get-Printer-Attributes (IPP/1.1)
< IPP 1.1 not supported
> Get-Printer-Attributes (IPP/1.0)
< OK, job-id 1234
> Get-Job-Attributes, job-id 1234
Printer never responds.
This seems to be a bug in the printer's IPP implementation. No response is ever
given to the Get-Printer-Attributes request.