Created attachment 800955 [details]
error_log (local print test)

(In reply to Damian Wrobel from comment #0)
> Created attachment 800954 [details]
> error_log (remote print test)

And this one is from the remote machine or from machine connected to the printer ?

(In reply to Jiri Popelka from comment #2)
> And this one is from the remote machine or from machine connected to the
> printer ?
Both are from the machine the printer is connected to. LogLevel was set to debug2.

192.168.160.9 is sending invalid application/vnd.cups-raster data.

How is that client configured? It seems to be running filters locally before sending the job to the CUPS server, but that's not the best way to do things and seems to be causing a problem here.

Rather than setting a driver for the remote printer, it should just send the data it gets from the application... in other words, it should be a 'raw' queue.

(In reply to Tim Waugh from comment #4)
> How is that client configured?

It was just automatically detected by the KDE printer manager (/usr/bin/kcmshell4 kcm_printer_manager). I've just selected the PPD and as aforementioned it worked fine up to the F18. On F19 I've even deleted and added again the printer but it didn't help.

Created attachment 802437 [details]
content of the /etc/cups directory from the remote machine

(In reply to Tim Waugh from comment #4)
> 192.168.160.9 is sending invalid application/vnd.cups-raster data.

I see that the /etc/cups/ppd/HP_DeskJet_930C.ppd on the remote machine contains the following line: 

*cupsFilter:    "application/vnd.cups-raster 100 rastertogutenprint.5.2"

Does that mean that this might cause the problem? But I didn't modify this file.

I've just commented out the cupsFilter line and the printing started to work.

Thank you very much for the hint you've provided.

Does that mean that I choose the wrong driver or it's a problem in the driver  (PPD file) itself?

It shouldn't have a driver at all. It needs to be a raw queue.

Try adjusting the queue like this:

lpadmin -p HP-deskJet_930C -m raw

Does that work?

(In reply to Tim Waugh from comment #9)
> Does that work?
Yes, that also works.

*** Bug 1012299 has been marked as a duplicate of this bug. ***

Hmm, there seem to have been several bugs like this, and really there's no reason it shouldn't work to have the filters run on the client.

Now that I look more closely at it I think I can see what's wrong: the filters converted the data (via application/vnd.cups-raster) to the printer's native command set (whatever that might be)... but when the job got sent to the CUPS server it was tagged as application/vnd.cups-raster rather than, say, application/octet-stream.

I wonder how long that's been broken.

Hi Tim
From my research to try to sort it out, it appears that it started to become a problem from CUPS 1.5.3 onwards.

OK, I can reproduce it here with cups-1.6.3-4.fc19.x86_64.

This looks like the culprit:

commit 44b1294cd4ab7940a5f79ca8022bf7a93b8e7486
Author: mike <mike@7a7537e8-13f0-0310-91df-b6672ffda945>
Date:   Tue Mar 19 18:35:14 2013 +0000

    Need to ignore trailing printer/foo null filter...
    
    
    git-svn-id: http://svn.easysw.com/public/cups/trunk@10918 7a7537e8-13f0-0310

diff --git a/scheduler/job.c b/scheduler/job.c
index cce4b39..aed35e2 100644
--- a/scheduler/job.c
+++ b/scheduler/job.c
@@ -635,10 +635,31 @@ cupsdContinueJob(cupsd_job_t *job)        /* I - Job */
       goto abort_job;
     }
 
-    /* SET FINAL_CONTENT_TYPE HERE */
+   /*
+    * Figure out the final content type...
+    */
+
+    cupsdLogJob(job, CUPSD_LOG_DEBUG, "%d filters for job:",
+                cupsArrayCount(filters));
+    for (filter = (mime_filter_t *)cupsArrayFirst(filters);
+         filter;
+         filter = (mime_filter_t *)cupsArrayNext(filters))
+      cupsdLogJob(job, CUPSD_LOG_DEBUG, "%s (%s/%s to %s/%s, cost %d)",
+                 filter->filter,
+                 filter->src ? filter->src->super : "???",
+                 filter->src ? filter->src->type : "???",
+                 filter->dst ? filter->dst->super : "???",
+                 filter->dst ? filter->dst->type : "???",
+                 filter->cost);
+
     if (!job->printer->remote)
     {
-      filter = (mime_filter_t *)cupsArrayLast(filters);
+      for (filter = (mime_filter_t *)cupsArrayLast(filters);
+           filter && filter->dst;
+           filter = (mime_filter_t *)cupsArrayPrev(filters))
+        if (strcmp(filter->dst->super, "printer") ||
+            strcmp(filter->dst->type, job->printer->name))
+          break;
 
       if (filter && filter->dst)
       {

cups-1.7-0.26.rc1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/cups-1.7-0.26.rc1.fc20

Package cups-1.7-0.26.rc1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cups-1.7-0.26.rc1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18188/cups-1.7-0.26.rc1.fc20
then log in and leave karma (feedback).

cups-1.7-0.26.rc1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Re-opening for Fedora 19.

*** Bug 1018030 has been marked as a duplicate of this bug. ***

cups-1.6.4-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cups-1.6.4-2.fc19

Package cups-1.6.4-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cups-1.6.4-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18910/cups-1.6.4-2.fc19
then log in and leave karma (feedback).

I can confirm that 1.6.4 fixes the bug.

Client:
Fedora 19 x86_64
cups 1.6.4-2

Server:
Fedora 19 x86_64
cups 1.6.3-4
with USB printer Samsung SCX-4623f

cups-1.6.4-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

cups-1.6.4-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

See bug #1149244. This patch is being reverted but I wasn't able to reproduce this bug after doing so.

I've been getting this between my F21 (client w/ cups-1.7.5-15 ) and RHEL6.6 (server w/ cups-1.4.2-67) machines using an HP F2480 deskjet printer.
Only way I've been able to work around is by following Comment #7 on the RHEL6.6 side. Following Comment #9 had no effect.
I realise this is closed, just wondering if something needs backporting or whether I'm doing something else terribly wrong.

Peter: what PPD is set for the local queue, and what PPD is set for the remote queue? i.e. what does 'sudo grep ^.NickName /etc/cups/ppd/myqueue.ppd' say, with the queue name substituted for myqueue, on each machine?

Hi,

I'm also hitting this bug. F21 client with cups 1.7.5-12, F20 server with cups 1.7.5-12.

Relevant lines in the cups error log:
D [28/Feb/2015:10:46:50 +0000] [Job 648] prnt/hpcups/HPCupsFilter.cpp 537: cupsRasterOpen failed, fd = 0
D [28/Feb/2015:10:46:50 +0000] [Job 648] PID 6638 (/usr/lib/cups/filter/hpcups) stopped with status 1.
D [28/Feb/2015:10:46:50 +0000] [Job 648] Hint: Try setting the LogLevel to "debug" to find out more.
D [28/Feb/2015:10:46:50 +0000] [Job 648] PID 6637 (/usr/lib/cups/filter/gziptoany) did not catch or ignore signal 13.
D [28/Feb/2015:10:46:50 +0000] [Job 648] prnt/backend/hp.c 896: ERROR: null print job total=0
D [28/Feb/2015:10:46:50 +0000] [Job 648] PID 6639 (/usr/lib/cups/backend/hp) exited with no errors.

Commenting out the *cupsFilter line in the ppd on the server fixes the issue, as per Comment #7.

Results of sudo grep ^.NickName /etc/cups/ppd/HP_Photosmart_C4400_series.ppd:

Client: *NickName: "HP Photosmart c4400 Series, hpcups 3.14.10"
Server: *NickName: "HP Photosmart c4400 Series, hpcups 3.14.10"

Cheers.

One more here:

 - F17 cups server working fine with F19 client
 --> upgrade F19 client to F21, printing ceases to work.

*cupsFilter commented in PPD on server, cups restart, printing works again.

*NickName: "HP Photosmart c4600 Series, hpcups 3.13.4"

cups is 1.7.5-13 on client, 1.5.4-22 on server.

Commenting out *cupsFilter is not correct and may lead to subtle bugs.

The correct solution is to do one of the following.

Either:

* Set the client queue as 'raw' so that all processing occurs at the server

Or:

* Set the server queue as 'raw' so that all processing occurs at the clients, and ensure that raw file printing is enabled in mime.types

(In reply to Tim Waugh from comment #28)
> Peter: what PPD is set for the local queue, and what PPD is set for the
> remote queue? i.e. what does 'sudo grep ^.NickName
> /etc/cups/ppd/myqueue.ppd' say, with the queue name substituted for myqueue,
> on each machine?

Apologies for taking so long to reply:
Both client and server have
*NickName: "HP Deskjet f2400 Series, hpcups 3.12.4"

Might I make a suggestion that, at least in F21 Gnome (yeah I know it's about to be obsoleted) that the lack of printing should be trapped better and that there be some non-command line UI to be able to change the client queue. If this has been improved in later releases, feel free to ignore me.

(Yeah, I 'fixed' it by "sudo lpadmin -p HP-Deskjet-F2400 -m raw" but I'm not totally convinced this is a suitable solution for SoHo setups)

Finally upgraded the print server to F21, went to redo the printer configuration even on client side (same F21 box as before) and sure enough this issue popped up again :)

As Peter, I went server-side and lpadmin'd -m raw the printer - first tests show that printing the client test page from CUPS HTTP GUI does work, even if the "Filter failed" message still appears client-side.

Only difference is that my server now runs XFCE - it used to run GNOME in fallback mode (Acer Aspire Revo with no real graphic accel to speak of), and F21 doesn't have usable ways to tone down its need for graphic accel (no, llvmpipe makes the CPU of my tiny Revo way too busy to run a VNC session decently). Don't know if that's relevant but I thought I'd mention it anyway.

BTW, shouldn't this bug stay in something else than CLOSED ERRATA?

Perhaps you did the configuration wrong?

The client set-up should simply be to add the 'ipp-client' and 'mdns' services to the firewall zone. After that, applications should discover the queue on the server and be able to print to it.

Some applications are using older toolkits which do not know how to perform this discovery (i.e. they don't use libcups). For those, you can use the cups-browsed service to automatically add local queues to forward jobs to discovered queues.

Configuration was entirely done via CUPS GUI, both at server and at client.

I just found out that my printer has decided to spit out some unfiltered
 PDF instead of nice printouts for some files, so I

 - deleted printer at server ('torrent') and client

 - added printer at server, which goes like

HP Photosmart c4600 Series hpijs, 3.14.10 (color, 2-sided printing)
hp:/usb/Photosmart_C4600_series?serial=CN03NH200405G0

 - added printer at client, which goes like

HP Photosmart c4600 Series hpijs, 3.14.10 (color, 2-sided printing)
dnssd://HP%20Photosmart%20C4600%20series%20%40%20torrent._ipp._tcp.local/cups

Entirely dropped the firewall at server side via iptables -F, and the test
 page printing from the CUPS GUI at client says

 processing since
Fri 05 Jun 2015 10:49:44 AM CEST 
"Filter failed"

...and performing

# lpadmin -pHP_Photosmart_C4600_series -m raw

 (this time correctly) on the client side allows my printing to go through.

(In reply to Alessandro Suardi from comment #35)
> Configuration was entirely done via CUPS GUI, both at server and at client.

CUPS GUI? You mean the web interface, localhost:631?

Yes - that's right, localhost:631 for my laptop client and torrent:631 for
 the Aspire Revo server.

I noticed I picked hpijs instead of hpcups this time around, though I don't
 think it should make a difference (it was both ways hpcups earlier on, it is
 both ways hpijs now) in the context of this specific issue.

Essentially, you should only specify the driver once, and ideally at the server end. With system-config-printer I believe this is done correctly at the client end (i.e. using a raw queue, sending the job as-is to the server).

I'm not sure I can agree here. The behavior of configuring via CUPS web the
 printers with drivers specified both at client and as server has worked
 flawlessly forever, up to F19 which broke stuff.

If F19 breakage is actually intended behavior change, then it's a CUPS web
 bug to let a user configure client-side driver without a big red flashing
 sign telling "are you sure? you should configure this driver ONLY at the
 server side AND set this printer up as RAW".

Which one would you pick? :)

In fact we dropped a patch to work around this as it was causing other problems. What you are seeing is the upstream behaviour.

I ran into the same error in Fedora Server 27 while printing from another distro (Ubuntu 16.04 LTS). Fedora client to Fedora Server prints without problems btw!. I support Tims theory (client to be configured with raw queue) because it solved the issue at my side. When I configured the client as Generic (local raw printer) I was able to print again without changing anything to my server configuration. Printing from Windows works fine too btw. On the client you see the error "filter failed" which seems to point to the ppd file, but raw printing solves. Hope this comment will help others running into the same issue.

I had this error today, printing from Fedora 26 client to Fedora 27 Server.
I commented out the *Cups-Filter lines in the HP .ppd file at the client - Everything then worked as expected.

Took some time before I found this bug described here.