Bug 135502 - cups printing same page repeatedly
cups printing same page repeatedly
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks: FC3Blocker
  Show dependency treegraph
 
Reported: 2004-10-13 00:06 EDT by Warren Togami
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 1.1.22-0.rc1.5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-14 06:37:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error_log (40.75 KB, text/plain)
2004-10-13 04:30 EDT, Warren Togami
no flags Details
capture.bz2 (37.53 KB, application/octet-stream)
2004-10-13 05:31 EDT, Warren Togami
no flags Details
capture.bz2 with -s 0 (362.94 KB, application/octet-stream)
2004-10-13 06:19 EDT, Warren Togami
no flags Details
cups-ippfail.patch (414 bytes, patch)
2004-10-13 07:34 EDT, Tim Waugh
no flags Details | Diff
error_log with .4 (71.16 KB, text/plain)
2004-10-14 05:19 EDT, Warren Togami
no flags Details
capture.bz2 with .4 (361.03 KB, text/plain)
2004-10-14 05:20 EDT, Warren Togami
no flags Details

  None (edit)
Description Warren Togami 2004-10-13 00:06:11 EDT
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
Comment 1 Warren Togami 2004-10-13 03:36:00 EDT
cups-1.1.22-0.rc1.1
Still broken with rawhide upgrade, along with Bug #135499 which I am
increasingly suspecting is related somehow.
Comment 2 Warren Togami 2004-10-13 03:47:32 EDT
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

Comment 3 Tim Waugh 2004-10-13 04:06:38 EDT
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.
Comment 4 Warren Togami 2004-10-13 04:30:35 EDT
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?
Comment 5 Tim Waugh 2004-10-13 04:57:41 EDT
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.)
Comment 6 Warren Togami 2004-10-13 05:04:48 EDT
Could you please provide me with the exact syntax for the tcpdump you
want?
Comment 7 Tim Waugh 2004-10-13 05:08:33 EDT
tcpdump -n -o capture port 631

ought to do what I want I think.
Comment 8 Warren Togami 2004-10-13 05:31:20 EDT
Created attachment 105128 [details]
capture.bz2

tcpdump -n port 631 -w capture
tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length
96)
Comment 9 Tim Waugh 2004-10-13 05:58:31 EDT
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.
Comment 10 Warren Togami 2004-10-13 06:19:26 EDT
Created attachment 105135 [details]
capture.bz2 with -s 0
Comment 11 Tim Waugh 2004-10-13 07:19:51 EDT
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.
Comment 12 Tim Waugh 2004-10-13 07:34:50 EDT
Created attachment 105136 [details]
cups-ippfail.patch

Here is the patch I'd like to try.
Comment 13 Tim Waugh 2004-10-13 07:42:23 EDT
Upstream as:

http://www.cups.org/str.php?L953
Comment 14 Tim Waugh 2004-10-13 08:18:59 EDT
Please try cups-1.1.22rc1-0.rc1.2.
Comment 15 Tim Waugh 2004-10-13 09:55:01 EDT
(Upstream maintainer says he'd prefer a different fix, but he's
looking at that.)
Comment 16 Warren Togami 2004-10-14 03:21:58 EDT
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.
Comment 17 Tim Waugh 2004-10-14 04:18:03 EDT
Please try cups-1.2.2-0.rc1.3.
Comment 18 Tim Waugh 2004-10-14 04:49:08 EDT
Er.. I mean cups-1.2.2-0.rc1.4. (This one'll work.)
Comment 19 Warren Togami 2004-10-14 05:19:05 EDT
Created attachment 105188 [details]
error_log with .4
Comment 20 Warren Togami 2004-10-14 05:20:33 EDT
Created attachment 105189 [details]
capture.bz2 with .4
Comment 21 Tim Waugh 2004-10-14 05:58:54 EDT
Please try cups-1.1.22-0.rc1.5.  I really think this will fix it now.
Comment 22 Warren Togami 2004-10-14 06:11:24 EDT
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.
Comment 23 Warren Togami 2004-10-14 06:12:33 EDT
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".
Comment 24 Tim Waugh 2004-10-14 06:37:29 EDT
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.
Comment 25 Warren Togami 2004-11-10 20:35:26 EST
Almost a month after sending notice to Linksys.  No response.
Comment 26 Shane Voss 2005-03-09 05:46:28 EST
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.)
Comment 27 Rob Latham 2005-12-09 23:24:39 EST
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


Note You need to log in before you can comment on or make changes to this bug.