Bug 122352 - Can *only* print test page for Xerox Phaser 8200 via IPP
Summary: Can *only* print test page for Xerox Phaser 8200 via IPP
Alias: None
Product: Fedora
Classification: Fedora
Component: cups   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-03 16:07 UTC by Jamin Gray
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-28 11:31:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cups error log (11.87 KB, text/plain)
2004-05-03 16:09 UTC, Jamin Gray
no flags Details
cups error log: debug2 (69.99 KB, text/plain)
2004-05-10 16:31 UTC, Jamin Gray
no flags Details
tcpdump capture (113.30 KB, text/plain)
2004-05-10 18:28 UTC, Jamin Gray
no flags Details
ipp strace (198.92 KB, text/plain)
2004-05-11 14:19 UTC, Jamin Gray
no flags Details

Description Jamin Gray 2004-05-03 16:07:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040422 Epiphany/1.1.12

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):

How reproducible:

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.

Additional info:

Comment 1 Jamin Gray 2004-05-03 16:09:46 UTC
Created attachment 99916 [details]
cups error log

This is the cups error log

Comment 2 Tim Waugh 2004-05-06 12:01:03 UTC
Is that with 'LogLevel debug2' set in /etc/cups/cupsd.conf?  There are
messages I'd expect to see but don't.

Comment 3 Jamin Gray 2004-05-10 16:31:49 UTC
Created attachment 100134 [details]
cups error log: debug2

New log file with LogLevel set to debug2

Comment 4 Tim Waugh 2004-05-10 17:44:23 UTC
Please run this command before you submit the print job:

tcpdump -w capture.log -s 0 -U host

and after, say, five minutes press control-C to stop it.  Then attach
capture.log to this bug report.  Thanks.

Comment 5 Jamin Gray 2004-05-10 18:28:40 UTC
Created attachment 100139 [details]
tcpdump capture

output of '/usr/sbin/tcpdump -w capture.log -s 0 -U host'

Comment 6 Tim Waugh 2004-05-11 10:40:52 UTC
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.

Comment 7 Jamin Gray 2004-05-11 14:19:08 UTC
Created attachment 100148 [details]
ipp strace

I've attached the output of an strace on the ipp process.  It seems to hang at
a 'recv(3,' call, never finishing...

Comment 8 Tim Waugh 2004-05-11 14:45:05 UTC

Comment 9 Tim Waugh 2004-05-11 15:28:45 UTC
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.

Comment 10 Tim Waugh 2004-05-11 17:39:45 UTC
The server end looks okay, because:

       "[...] for
        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-
        continue" expectation."
          -- 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)
          if (httpCheck(http))
-           break;
+         {
+           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);
+  check_status:
     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?

Comment 11 Jamin Gray 2004-05-11 17:51:40 UTC
Tim, you're amazingly efficient.  The patched rpms work great.  I'm
able to print just fine with them.  

Comment 12 Tim Waugh 2004-05-12 09:37:53 UTC
Thanks for testing.  Upstream as: http://www.cups.org/str.php?L716

Comment 13 Dax Kelson 2004-05-18 21:04:52 UTC
Can this be pushed out as an errata for FC2? This impacts me greatly.

Comment 14 Tim Waugh 2004-05-19 13:45:47 UTC
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.)

Comment 15 Tim Waugh 2004-09-28 11:31:38 UTC
This update has been released.

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