From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
We have a Xerox Phaser 8200 printer on our network with it's own ip
address (i.e. there is no print server). Users can print fine from
Windows, Mandrake, and Redhat 9. I'm using Fedora Core - test3 and
can only print the test pages. Nothing else prints from any
application. Since the Phaser 8200 is not listed in the supported
devices list of the printer configuration tool, I've tired "Generic
Postscript" and "Raw Print Queue". In both cases the results are the
same: the test pages print but nothing else does. No errors are
reported. The printer claims to be receiving the document for a while
but never prints it. The document stays in the print queue (according
to the output of 'lpq').
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add a new queue of type "Networked CUPS (IPP)"
2. Enter the ip address of the printer on the network.
3. Select "Postscript Printer" or "Raw Print Queue"
4. Finished. Now print a test page. Yep, it prints.
5. Go to any application, such as gedit and try to print a document.
Actual Results: Only the test document prints. Nothing else.
Expected Results: Documents should print from any application.
Created attachment 99916 [details]
cups error log
This is the cups error log
Is that with 'LogLevel debug2' set in /etc/cups/cupsd.conf? There are
messages I'd expect to see but don't.
Created attachment 100134 [details]
cups error log: debug2
New log file with LogLevel set to debug2
Please run this command before you submit the print job:
tcpdump -w capture.log -s 0 -U host 192.168.33.104
and after, say, five minutes press control-C to stop it. Then attach
capture.log to this bug report. Thanks.
Created attachment 100139 [details]
output of '/usr/sbin/tcpdump -w capture.log -s 0 -U host 192.168.33.104'
It doesn't look like the job gets transferred to the printer at all.
All that happens is that the printer is asked what document formats it
accepts; then the connection is closed and never re-established.
After you submit the print job, is there a process named 'ipp' (or it
might look like an 'ipp://...' URI) on the client machine? It would
be useful to see the output of 'strace -p 6325' (or whatever PID that
process has) if so.
Created attachment 100148 [details]
I've attached the output of an strace on the ipp process. It seems to hang at
a 'recv(3,' call, never finishing...
Okay, I see why the code is in recv(). So the question becomes one of
blame: whether CUPS is right to expect more data or not. I'll need to
figure this out from the HTTP RFC.
The server end looks okay, because:
compatibility with RFC 2068, a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
-- RFC 2616, 8.2.3
and that's the situation we find ourselves in.
I've made a small change to cups/util.c like this:
--- cups-1.1.20/cups/util.c.continue 2004-05-11 17:52:08.000000000
+++ cups-1.1.20/cups/util.c 2004-05-11 17:57:48.000000000 +0100
@@ -293,7 +293,11 @@
while ((bytes = fread(buffer, 1, sizeof(buffer), file)) > 0)
+ status = httpUpdate (http);
+ if (status != HTTP_CONTINUE)
+ goto check_status;
if (httpWrite(http, buffer, bytes) < bytes)
@@ -308,6 +312,7 @@
while ((status = httpUpdate(http)) == HTTP_CONTINUE);
DEBUG_printf(("cupsDoFileRequest: status = %d\n", status));
if (status == HTTP_UNAUTHORIZED)
The intention is to ignore the normal continuation processing until
after the entire file is sent. I'm hoping that this will prompt the
printer to give a status code other than 100 Continue.
There is a test package with this change at this address:
Please could you try it out and let me know how it gets on?
Tim, you're amazingly efficient. The patched rpms work great. I'm
able to print just fine with them.
Thanks for testing. Upstream as: http://www.cups.org/str.php?L716
Can this be pushed out as an errata for FC2? This impacts me greatly.
Yes, I intend to release this as an update to FC2. I'd like to
collect up some more fixes first, and there is also a possibility of
upgrading to 1.1.21 as well if that comes out fairly quickly.
(In the mean time you can use the Fedora development package at
which contains this fix.)
This update has been released.