Bug 122352

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]
tcpdump capture

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]
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...

Thanks.

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:

       "[...] 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
+0100
+++ 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)
             break;
@@ -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:

ftp://people.redhat.com/twaugh/tmp/cups-continue/

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
http://download.fedora.redhat.com/pub/fedora/linux/core/development/,
which contains this fix.)

This update has been released.