Hide Forgot
Description of problem: When I try to print a file on a network printer (with IPP protocol), the file is constanly printed because the job remains in queue. In consequence, the file is printed again and again.. Version-Release number of selected component (if applicable): CUPS 1.5.0 on Fedora-16 The printer is a Xerox WorkCentre 5632 and is configured as a generic PostScript printer because the driver for WorkCentre 5632 from Xerox doesn't work on Linux. How reproducible: Print a file or a test page on a network printer. Steps to Reproduce: 1. Configure a network printer using IPP protocol with system-config-printer. 2. Print a test page from system-config-printer. 3. Actual results: The test page is printed indefinitely and the job must be manually killed. Expected results: The test page must be printed once only. Additional info: The Xerox WorkCentre 5632 supports IPP/1.1 but not IPP/2.0. In the /var/log/cups/error_log, I've the following lines: Backend returned status 7 (unknown) Retrying job on same printer. End of messages printer-state=3(idle) printer-state-message="Unable to get print job status." printer-state-reasons=none Unable to get printer status. The ipptool command reports the following lines: # ipptool "ipp://xerox5632/ipp" ipp-1.1.test unknown-d838 Bad version 16.44 in response - expected 1.1 (RFC 2911 section 3.1.8). Bad request ID 271370560 in response - expected 0 (RFC 2911 section 3.1.1) "printer-state": Bad enum value 0 - out of range (RFC 2911 section 4.1.4). "printer-current-time": Bad dateTime UTC hours 255 (RFC 2911 section 4.1.13). EXPECTED: STATUS client-error-bad-request (got unknown-d838) NOT EXPECTED: printer-uri-supported The status (d838 in the previous example) is a random value and change at each ipptool command.
It would be very useful to be able to see the IPP communications between the Fedora system and the Xerox printer. Please run this command, as root, to capture it (you may need to install the 'tcpdump' package first): tcpdump -n -i p4p1 -s0 -U -w ipp.pcap port ipp (your network interface name may differ from 'p4p1' -- use '/sbin/ifconfig' to find its name if so) When that command is running, print a test page and wait until it comes out of the printer twice. Then manually kill the job as before. Press Control-C on the tcpdump command to stop it, and then please attach the ipp.pcap file here using the "Add an attachment" link above. Thanks.
Created attachment 533935 [details] ipp.pcap file compressed with gzip
Thanks. It looks like the printer's support for the IPP protocol is a little off. IPP request (v2.0) 60408: Get-Printer-Attributes (ipp://129.182.147.116:631/ipp) IPP response (v1.0): Server-Error-Version-Not-Supported === IPP request (v1.1) 60409: Get-Printer-Attributes (ipp://129.182.147.116:631/ipp) IPP response (v1.1): Successful-OK-Ignored-Or-Substituted-Attributes (but printer-state is 0, which is not a valid value) IPP request (v1.1): Validate-Job IPP response (v1.1): Successful-OK IPP request (v1.1): Print-Job IPP response (v16.44): 0xc240 (invalid status code) (has wrong request ID) In other words, the printer is responding to the Print-Job request with a nonsense status code, with an incorrect request ID, and with a garbage IPP version. Perhaps there is another protocol that could be used for this printer instead of IPP? Closing as NOTABUG as I believe CUPS is behaving correctly here.
I've added the options waitjob=false and waitprinter=false in the URI of the Xerox printer like this: ipp://129.182.147.116:631/ipp?waitjob=false&waitprinter=false and it's OK. Now, files are correctly printed and jobs are removed from queue. Cordially.