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):
Still broken with rawhide upgrade, along with Bug #135499 which I am
increasingly suspecting is related somehow.
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
/sbin/service cups start
and make the problem occur again. Then please attach error_log.
Created attachment 105121 [details]
* 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
tcpdump -n -o capture port 631
ought to do what I want I think.
Created attachment 105128 [details]
tcpdump -n port 631 -w capture
tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length
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
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
Up to LinkSys to fix this really. We can't go second-guessing corrupt
However, I can try to fix CUPS to fail better in this situation.
Created attachment 105136 [details]
Here is the patch I'd like to try.
Please try cups-1.1.22rc1-0.rc1.2.
(Upstream maintainer says he'd prefer a different fix, but he's
looking at that.)
E [13/Oct/2004:21:23:50 -1000] [Job 1] Print file was not accepted
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.
E [14/Oct/2004:00:09:02 -1000] [Job 1] Print file was not accepted
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