Description of problem: Print jobs seem to be printing in an infinite loop until all paper is gone. I am unable to cancel the jobs in gnome-printinfo, and soon later Bug #135499 happens. Meanwhile the printer continues to print the same page repeatedly. I was forced to stop service cups and clean out /var/spool/cups to stop it. I was able to reproduce this from the CUPS test page, and a full screen graphic printed from KView. Version-Release number of selected component (if applicable): cups-1.1.21-7
cups-1.1.22-0.rc1.1 Still broken with rawhide upgrade, along with Bug #135499 which I am increasingly suspecting is related somehow.
More Details: My laptop is configured to print using CUPS using IPP 1.0 to my Linksys print server. The print server is plugged in via USB to my Epsons Stylus C84 inkjet printer. This process below seems to linger. root 4829 4780 0 21:33 ? 00:00:00 ipp://172.31.16.3/printers/queue1 2 root testprint.ps 1 page-bottom=86 cpi=12 page-right=57 page-left=57 page-top=72 scaling=100 lpi=7 wrap
Please alter /etc/cups/cupsd.conf and set LogLevel to debug2, then: /sbin/service cups stop >/var/log/cups/error_log /sbin/service cups start and make the problem occur again. Then please attach error_log. Thanks.
Created attachment 105121 [details] error_log * error_log from "service cups start" with an empty to queue. * CUPS test page from system-config-printer. I [12/Oct/2004:22:30:05 -1000] [Job 1] Printer is busy; retrying print job... This happened when the printer was about 30% done printing the page. Somehow cups thinks that the printer failed so it tries again?
Please can you capture a tcpdump of this exchange? It will all be on TCP port 631. Thanks. (The raw pcap file will be best.)
Could you please provide me with the exact syntax for the tcpdump you want?
tcpdump -n -o capture port 631 ought to do what I want I think.
Created attachment 105128 [details] capture.bz2 tcpdump -n port 631 -w capture tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 96)
Sorry, I meant to add '-s 0' to the command line (some of the captured frames are short). Can you try again with this please?: tcpdump -n -w capture -s 0 port 631 Thanks.
Created attachment 105135 [details] capture.bz2 with -s 0
The problem comes from packet 1269, coming from the linksys server (a PSUS4 I think you said it was): In the 'attributes-natural-language' operation attribute we have this: 48 (Natural language tag) 00 1b (name length 27) 61 74 74 72 69 62 75 74 65 73 2d 6e 61 74 75 72 61 7c 2d 6c 61 6e 67 75 61 67 65 ('attributes-natural-language') 00 05 (value length 5) 02 45 00 07 6a (junk) In fact, the 6a is the first byte of 'job-uri', so I think the value length was intended to be 4 instead of 5. One can only guess what the intended value was! This indicates a bug in the LinkSys device. Had the length been 4 the rest would have decoded nicely, with a job ID and everything. Up to LinkSys to fix this really. We can't go second-guessing corrupt IPP packets. However, I can try to fix CUPS to fail better in this situation.
Created attachment 105136 [details] cups-ippfail.patch Here is the patch I'd like to try.
Upstream as: http://www.cups.org/str.php?L953
Please try cups-1.1.22rc1-0.rc1.2.
(Upstream maintainer says he'd prefer a different fix, but he's looking at that.)
Bad news... E [13/Oct/2004:21:23:50 -1000] [Job 1] Print file was not accepted (server-error-service-unavailable)! And it attempts to print again.
Please try cups-1.2.2-0.rc1.3.
Er.. I mean cups-1.2.2-0.rc1.4. (This one'll work.)
Created attachment 105188 [details] error_log with .4
Created attachment 105189 [details] capture.bz2 with .4
Please try cups-1.1.22-0.rc1.5. I really think this will fix it now.
Bad news... E [14/Oct/2004:00:09:02 -1000] [Job 1] Print file was not accepted (server-error-service-unavailable)! But it at least stops rather than attempting to print another page. But this is still bad, because that job is stuck in the queue as "Printing" and all subsequent jobs are stuck in "Pending" status. Should we just accept that the Linksys PSUS4 is just too buggy to be usable with IPP? The 'unable to cancel print job' part of this bug seems to be Bug #135499.
Hmm, not a great idea to accept this situation. cups really needs to handle bad IPP hardware more gracefully than "print until paper is exhausted" or "jam the print queue".
Not a lot we can do about it -- the linksys device really is broken, and to throw the job away without knowing that it has hit paper would be a bit bold. I note that you tried forcing IPP/1.0 without any change in behaviour, so defaulting to that wouldn't help. We're at the end of the line for things that we can do in CUPS, really. Time for you to complain to your print server vendor.
Almost a month after sending notice to Linksys. No response.
I found a work-around for this elsewhere. By telling CUPS to use lpd://name.of.box/USB1 I was able to actually use the thing! (I don't think this lets Linksys off the hook, but it saved me returning it as useless/faulty.)
googling for 'cups linksys' led me here, so i just wanted to share my experience. The name of the linksys PSUS4 (firmware version 6033) lpd spool was L1. i.e. the CUPS uri should look like lpd://192.168.XX.YY/L1