Bug 323311

Summary: Get-Job-Attributes returning job not found error should result in cups marking job complete
Product: [Fedora] Fedora Reporter: Trever Adams <trever>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-12 16:47:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235704    
Attachments:
Description Flags
The capture bziped none

Description Trever Adams 2007-10-08 16:58:00 UTC 
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):
cups-1.3.3-1.fc8

How reproducible:
Always

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)
  
Actual results:
"Waiting for job to complete..."

Expected results:
Job is finished and cups recognizes it.
Comment 1 Tim Waugh 2007-10-09 12:41:25 UTC 
It already does this:

      if (ipp_status == IPP_NOT_FOUND)
      {
       /*
        * Job has gone away and/or the server has no job history...
	*/

        ippDelete(response);

	ipp_status = IPP_OK;
        break;
      }

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
Comment 2 Trever Adams 2007-10-09 15:35:05 UTC 
I will be able to provide this later this evening (+8 hours or so from now).
Comment 3 Trever Adams 2007-10-10 18:55:54 UTC 
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.
Comment 4 Trever Adams 2007-10-10 18:56:53 UTC 
Created attachment 223251 [details]
The capture bziped
Comment 5 Tim Waugh 2007-10-12 16:47:57 UTC 
Okay, I think this is the queue you're printing to:
  ipp://usr7500-EBA13B.localdomain:631/ipp/ports

This proceeds as follows:
> Get-Printer-Attributes (IPP/1.1)
< IPP 1.1 not supported
> Get-Printer-Attributes (IPP/1.0)
< OK
> Print-Job
< OK, job-id 1234
> Get-Job-Attributes, job-id 1234
< Client-Error-Not-Found
> Get-Printer-Attributes
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.