CUPS IPP print to Novell servers error since 11.10 upgrade

I have attached an example CUPS log to this comment to demonstrate the problem.

Looking at the source more closely, it appears that the initial test for Validate-Job succeeds, but actually using it before printing fails. One very quick way to test this would be to find the line "while(!job_canceled && validate_job)" (1229 upstream), and simply put "validate_job = 0" on the line above this. That should skip the attempt to use Validate-Job. Longer term, this might have to become a configurable option, either globally or per IPP printer.

Can you provide a simple patch which works around the bug? We could solve the problem for Oneiric then.

Independent of this, can you post a bug to CUPS upstream on

http://www.cups.org/str.php

Thanks.

I've got excatly the same problem with a HP PSC 1510 which however is absolutely recognized.

It's possible to print when it's directly connected to the PC.
On the other hand, when it's connected on the network using my LiveBox2 I get the message "cups-ipp-missing-validate-job" and "Print file was not accepted".
I'd like to indicate I'm not alone as this can show it

http://forum.ubuntu-fr.org/viewtopic.php?id=685831

Hi,
Like GALLINARI, I confirm this bug under 11.10 with a Canon Pixma iP4500 connected by USB to a Livebox2 (modem router ADSL). Under 10.10 and 11.04 there wasn't any problem : I could print using IPP. But since I upgraded to 11.10 it's impossible. I can print if I connect directly my printer to my laptop via USB.

Quick update:

The bug is now filed upstream as requested (http://www.cups.org/str.php?L3967+Qversion:1.5). I also attempted to force validate_job to zero in backend/ipp.c, as I suggested earlier. So far, however, the result of that was to get "server-error-service-unavailable" errors when the actual Print-Job request occurs!

(I should also apologise at this point, since on re-reading http://www.cups.org/documentation.php/spec-ipp.html, it looks like Validate-Job is in fact part of the core IPP specification after all, and so would be expected to exist!)

OK, as a quick fix, I have effectively replaced backend/ipp.c with the 1.4.x version (branches/1.4.x/backend/ipp.c, r8950), with the patch included below. One line was changed in order to get the code to compile as part of 1.5:

----------------------------
--- ipp-1.4x.c 2011-10-27 16:50:04.000000000 +0100
+++ ipp.c 2011-10-27 16:37:46.000000000 +0100
@@ -428,7 +428,7 @@

     if ((fd = cupsTempFd(tmpfilename, sizeof(tmpfilename))) < 0)
     {
- _cupsLangPrintError(_("ERROR: Unable to create temporary file"));
+ _cupsLangPrintError("ERROR", _("Unable to create temporary file"));
       return (CUPS_BACKEND_FAILED);
     }

----------------------------

I would not trust this without a lot more testing, but this worked for me just now.

Thank you very much Robert,
Your patch works fine for me : now I can print like under 10.10 and 11.04.
Besides I learned how patching : I had never made this before

For those who would try this you can download the source of cups here : http://archive.ubuntu.com/ubuntu/pool/main/c/cups/cups_1.5.0.orig.tar.bz2

It's easier to use "apt-get source cups" to fetch the source code, since then you get the latest source code with the Ubuntu/Debian patches applied too. The orig.tar.bz2 file is actually the unaltered CUPS source.

At the risk of being slightly off-topic, these instructions should work for building and replacing the ipp backend manually:

* Download the patch file in my previous comment.
* Run "mkdir cups && cd cups && apt-get source cups" to fetch Ubuntu's source code for CUPS and place it in its own directory.
* Change to the "cups-1.5.0" directory, then run "patch -p1 < ipp-patch-file", where ipp-patch-file is the location of the patch file.
* Run "./configure"

Normally you would do "make && sudo make install", compiling the entirety of CUPS (you'll need the po4a package installed first). We have CUPS installed already though, so to save time we can just compile the contents of the "backend" directory on their own:

* "cd backend && make"
* Run these next two commands to back up the existing ipp backend file and replace it with the new one:
 - "sudo cp /usr/lib/cups/backend/ipp /usr/lib/cups/backend/ipp-backup"
 - "sudo cp ./ipp /usr/lib/cups/backend/ipp"

Thanks for yours intructions in order to patch correctly.

For me you aren't at all off-topic : I had to find myself how to patch and there aren't much informations that explain how to make it properly.
So I'm going to translate in french yours advices to help others users.
Regards

Setting to "Confirmed" as a working solution is presented here. Not yet "Triaged" as it needs to be discussed whether this solution should really get applied. Downgrading the backend from 1.5.0 to 1.4.x is a rather big patch and probably pulls out many features, not only the feature which caused the regression. What we need, especially for an SRU in Oneiric, is to really find out what caused the regression and pull out only that feature or better fix it.

For those who want explanations in french, you can find them here : http://forum.ubuntu-fr.org/viewtopic.php?pid=6787401#p6787401

Another update:

First, for the instructions I posted yesterday, you do in fact need to build the whole of CUPS for them to work.

Secondly, I did a bit of digging through Wireshark dumps last night, and found out that the Validate-Job calls were not the whole story. It turns out that CUPS 1.5 adds a document-format attribute to its print jobs. It appears to dig through the server response for supported types, and if it does not match a MIME type to that of the document, it assumed "application/octet-stream". This then got rejected by the server.

The patch attached here replaces that assumed value with NULL, which results in the attribute being skipped. This replicates the 1.4 behaviour, although we still get the complaints over IPP compliance. I also added a bit of debug-level logging around the document-format discovery area of the code.

ThierryM: would you be willing to try this new version and see if it prints for you?

Robert, does applying only the patch attached to your comment #12 fix the problem? It is a simple small patch which we could easily make available to our users as a Stable Release Update (SRU) for Oneiric. If additional patches are needed, please tell me the minimum set of patches needed to solve the problem. Thanks in advance.

Till: yes, applying just the patch from comment 12 fixes the problem for me. I do not feel that any additional patches are needed, simply because the new patch behaves in the same way as the code from 1.4.6, and that appears to work fine for everyone. So, if the comment #12 patch also works for ThierryM, I would suggest using that patch as-is.

The missing-validate-job message will still appear briefly with this patch applied, but is just a cosmetic issue now. It has no effect with regards to actually printing the document, for me at least. If people wanted it, I could reintroduce the patches to block the validate-job requests entirely. To be honest though, we're probably better off sticking to the current patch.

Robert, thank you very much.

ThierryM, can you please apply Robert's patch from comment #12 to the original Ubuntu package of CUPS, and no other patches. Can you test whether only this change is enough in Oneiric's CUPS to solve your problem? Thanks in advance.

The attachment "Patch: replaces backend/ipp.c with the 1.4.x version (branches/1.4.x/backend/ipp.c r8950)" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Hi,
I tested the patch #12 alone (I desinstalled CUPS, downloaded the source package, I patched with the patch #12) and it doesn't solve my problem : the bug seems the same.

Thierry,

I would be interested in seeing what CUPS is sending to the print server. Would you be willing to submit a debug log and the results of "tcpdump -i eth0 -p port 631 > packetlog" showing an attempt at printing the Ubuntu test page?

Thanks in advance,

Robert

Better make that "sudo tcpdump -i eth0 -p -w packetlog port 631" (or alternatively, use Wireshark with capture filter "port 631").

One final point: if you are happy to collect the IPP packets, it would be very useful if I looked at logs/packet dumps for both the new (broken) patch, and the previous one which worked for you. That way, I ought to be able to see just what is different between the two versions! Either emailing them to me or attaching them is fine from my point of view.

Hi Robert,
Like I print from my laptop via wifi I did : "sudo tcpdump -i wlan0 -p -w packetlog port 631". I hope I did right.
I join the packetlog.

The previous "packetlog" was obtained with the first patch that's working. Do you want an other packetlog with the broken patch ?

Hi Thierry,

Yes, please! :)

So, there's the packetlog2 with the broken patch.

Hi Thierry,

Thanks for the packet logs - they were very interesting! It looks to me as if CUPS is continually trying to talk to your print server using IPP/2.0, which it does not appear to support. With the present code, CUPS expects it to return an error of IPP_VERSION_NOT_SUPPORTED, which is used as a hint to downgrade the connection. In practice, your server acts in a similar way to Web servers, and returns a response as IPP/1.0.

Would you mind applying the following inline patch to the existing version from comment #12 and seeing if that helps?

=== modified file 'backend/ipp.c'
--- old/backend/ipp.c 2011-10-28 09:12:41 +0000
+++ new/backend/ipp.c 2011-10-29 00:11:43 +0000
@@ -247,6 +247,7 @@
   ppd_file_t *ppd; /* PPD file */
   _ppd_cache_t *pc; /* PPD cache and mapping data */
   fd_set input; /* Input set for select() */
+ int server_ipp_version;

  /*
@@ -830,6 +831,18 @@

     supported = cupsDoRequest(http, request, resource);
     ipp_status = cupsLastError();
+
+ /* Extract server IPP version, and use this to downgrade */
+ server_ipp_version = supported->request.any.version[0]*10;
+ server_ipp_version += supported->request.any.version[1];
+ if (version > server_ipp_version)
+ {
+ fprintf(stderr, "INFO: Server responded to our IPP/%d.%d request ",
+ version / 10, version % 10);
+ fprintf(stderr, "with an IPP/%d.%d response - downgrading!\n",
+ server_ipp_version / 10, server_ipp_version % 10);
+ version = server_ipp_version;
+ }

     fprintf(stderr, "DEBUG: Get-Printer-Attributes: %s (%s)\n",
             ippErrorString(ipp_status), cupsLastErrorString());

Actually, before testing the patch in my previous comment, try changing your printer URI to "ipp://192.168.1.1:631/ipp?version=1.0" briefly, and see if that works. If it does, then we know it's a protocol version issue, and testing the patch would then make sense.

I also think it might be worth me repositioning the code within that patch so that it is only called if the existing downgrade code finds nothing wrong. (Otherwise, we may end up downgrading further than we have to.)

Hi Robert,
I have applied the last patch over CUPS yet patched with the patch in the message #6 but the problem still exists : thre's no amelioration.
I join the packetlog3 to look it.

Sorry but I posted my previous message without reading the message #27.
But when I use "ipp://192.168.1.1:631/ipp?version=1.0" the problem still exists.

Sorry again but in my message #28 it's not the patch in message #6 : I made a mistake when I wrote, I used CUPS patched with the patch in the message #12 to do the test.

Thierry,

The packetlog3 file was interesting because it looks like it's downgrading to IPP/1.0 fine now! So, time for me to figure out why you're getting HTTP 400 (Bad Request) errors from it...

This looks like it is a separate bug from the original bug reported here, which comment #12 seems to fix well enough. Perhaps we should get this split out into its own bug report and continue working on this there?

Robert,
For me, I'm not capable to distinct that there is 2 différents bugs :-) : so do what you think fair or more efficient. If you split, could you indicate the new number of the bug ?
Thank you for your job because now with the first patch I can again print through the network.
Regards

Thanks for your patience with this, Thierry, it's much appreciated! I'll leave the bug splitting decision to Till, I think. In the meantime, I have another full patch to try. This one is inspired by the fact that the old version never tried to use the "Expects: 100-continue" header - instead, it just sent the whole file straight away. You get a new IPP option "nohttpcontinue=yes" to test, similarly to "version=1.0" before. However, this should also set itself when the first submission fails, with a message in the error log.

Robert, I think a second bug report is not needed. As soon as you have solved the problem with Thierry, I will apply the complete set of patches (and also forward it upstream).

I patched the original CUPS with the last cumulative patch but it doesn't work.
Here the log package4.

Is that with or without the nohttpcontinue option (URI ipp://192.168.1.1/ipp?nohttpcontinue=yes)? At the moment, it looks near-identical to the previous log - the patches did nothing! :(

With the 2 URI "ipp://192.168.1.1/ipp?nohttpcontinue=yes" and "ipp://192.168.1.1/ipp", the cumulative patch doesn't work.

Thanks - now it's time for me to figure out why nothing changed!

Hi, I'm using Kubuntu 11.10 and I have the same issue with a
U.S. Robotics Wireless MAXg ADSL Gateway
with a HP Laserjet 6L connected through the usb connection (using a paraller to USB connector)
The patch at #12 worked for me and just to recap I followed the following steps:

* install with synaptic or other package manager "po4a"
* Run "mkdir cups && cd cups && apt-get source cups" to fetch Ubuntu's source code for CUPS and place it in its own directory.
* Change to the "cups-1.5.0" directory, then run "patch -p1 < ipp-patch-file", where ipp-patch-file is the location of the patch file.
* Download the patch file in comment #12
* Run "./configure"
* Run "make"
* Run these next two commands to back up the existing ipp backend file and replace it with the new one:
 - "sudo cp /usr/lib/cups/backend/ipp /usr/lib/cups/backend/ipp-backup"
 - "sudo cp ./ipp /usr/lib/cups/backend/ipp"

Thanks all for the help on this!
Note: if I try to install the patched version on its own the KDE printing doesn't work.

Sorry, I try again:

* install with synaptic or other package manager "po4a"
* Run "mkdir cups && cd cups && apt-get source cups" to fetch Ubuntu's source code for CUPS and place it in its own directory.
* Change to the "cups-1.5.0" directory,
* Download the patch file in comment #12
* Run "patch -p1 < ipp-patch-file", where ipp-patch-file is the location of the patch file.
* Run "./configure"
* Run "make"
* Run these next two commands to back up the existing ipp backend file and replace it with the new one:
 - "sudo cp /usr/lib/cups/backend/ipp /usr/lib/cups/backend/ipp-backup"
 - "sudo cp ./ipp /usr/lib/cups/backend/ipp"

The latest update on the upstream bug is that it is the Novell (and Livebox2) servers at fault, and not CUPS. The bug has been "Closed w/o Resolution". I have no idea where this leaves us long-term - presumably trying to write our own patch to successfully disable chunking (fixing the Livebox2 issue?), and using the existing patch from #12 to work around the Novell issue.

Hi Robert,
Thanks for your information. But I don't understand why the Livebox2 worked fine before with the older CUPS ? And why the Livebox2 works under Windows ?
I regret my upgrade to Oneiric : Maverick 10.10 worked much better for printer (USB detection doesn't work too for my printers MP240 and iP4500).
Other solution, It's possible to downgrade CUPS ?
Anyway thank you for your patch very usefull.
Regards

I've not tried it, but Windows probably works fine because it avoids HTTP chunked transfers, like CUPS 1.4 does.

I've no idea if it would work or not, but you could try removing the CUPS packages, and then playing with apt pinning to force those to be reinstalled from the Lucid repositories. I have no idea if that would work well, and it's not an ideal solution in any case, but may be the only option.

I have the following server:

U.S. Robotics Wireless MAXg ADSL Gateway

So, it sounds strange that Novell, Livebox 2 and MAXg are faulty, after CUPS update.

Also in my case, Windows XP, Windows 7 and Kubuntu 11.04 worked totally fine with the same configuration...

OK, I think I might finally have this HTTP chunking issue sorted, at least partially. In the case where only one job is sent at one (so IPP's Print-Job is used instead of Create-Job), the attached patch prevents the use of HTTP chunking for me.

This needs to be enabled by setting your printer URI to "ipp://<printserver>/ipp/printername?nohttpchunking=yes". At that point, the printer is treated as if it does not understand HTTP/1.1 in the code.

Notes:

1. I still get the Expect: 100-continue header for some reason, regardless of my attempts to disable it, so I gave up there.
2. The Novell servers I have access to work regardless - they only require the document-format patch in comment 12.

As it turned out, whilst the previous patch works, there was one issue: part of the data stream from the printer driver was lost! This only occurs when using the Content-Length fallback code, which I force on with the previous patch.

Gory details:

For the fallback, the IPP backend copies the data to a temporary file, and fetches the file size (using backendRunLoop). Unfortunately, earlier on in the code, it reads from stdin to a buffer, which is forgotten about in the fallback case! The end result was corruption of printouts using PCL drivers.

I have now added yet another fix to the IPP backend to write this initial data out to the temporary file and update the length accordingly. This version now prints correctly, as confirmed with hard copy.

ThierryM and others with Livebox2 routers: could you please check that this prints when nohttpchunking is enabled as above?

Hi,

I also experiment the same issue since I updated to Oneiric. My ADSL/modem "BBox2" router is branded by another french provider "Bouygues", but it's in fact the same device : SAGEM f@st 3504.

I'll try you patch and give you some news.

Thxs for all

Great : using patch of comment #46, it works for me but with two visible non-fatal errors :

cups-ipp-missing-job-history
spool-area-full

Notice that I had to create a "new" printer using the new URI "ipp://<printserver>/ipp/printername?nohttpchunking=yes" to avoid to get the printer status "no profiles specified in PPD"

I apologize, but I didn't succeed in looging a tcpdump, i got only empty files (after changing the network device).

Mavosaure, thanks for testing the patch for me. There is no need to worry about the tcpdumps, given it worked as expected, but don't let that stop you! It may help me with the two messages you saw, which I am a little surprised by. You can try clearing out /var/spool/cups to see if that sorts out the "spool area full" message (but I expect this is server-side). The missing-job-history message is most likely another cosmetic complaint about IPP specification compliance. It can also apparently occur if the job disappears from the print server. It seems to be working though, which is better than last week!

Hi,
I tried the last patch #46 and it's working but I have first this message : "spool-area-full" before the printing succeed.
The URI printer is "ipp://192.168.1.1:631/ipp/Canon-Livebox2?nohttpchunking=yes" ( the name of my printer is Canon-Livebox2).
I join the result of the command "tcpdump -i wlan0 -p -w packetlog5 port 631".
Regards

Hi all,

This is just a guess, but one thing you could try is setting the IPP version. The patch here removes my auto-downgrade code, so you should be able to test using the following URIs:

ipp://192.168.1.1:631/ipp/printer?nohttpchunking=yes
ipp://192.168.1.1:631/ipp/printer?nohttpchunking=yes&version=1.1
ipp://192.168.1.1:631/ipp/printer?nohttpchunking=yes&version=1.0

I don't know if this will fix this spool-area-full message, but it can't hurt trying it. Version 1.1 ought to match CUPS 1.4.6.

Thanks again for your patience everyone!

I patched directly with the minus auto-downgrade. I obtain the same results with the 3 URIs.
But I noticed (and perhaps with the patch #46 too) that I can print the first page diretly but after I had to push the button on the printer to feed paper in order to print.
I have always the "spoll-area-full" message and an other (until I push the button) that says "copying print data".

The "Copying print data" message is safe enough - that's generated when the fallback code copies the print job to disk. The spool-area-full part seems to be the server's fault, and appears during the processing stage (we seem to get multiple connections too). Your CUPS 1.4.6 logs don't show any requests for printer state during printing, which might explain why it's started appearing now!

What's interesting here is that this pausing behaviour sounds very similar to this bug:

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/877958

Could we be hitting this same bug somehow? With misleading status messages, it's entirely possible...

Since my uni uses Novell infrastructure, I tried Robert's patch from comment #12, and that seems to solve the problem for me.

IPP backend reverted to the version of CUPS 1.4.x to fix bug 881843, bug 877958, bug 879625, and bug 883585 for the time being until the backend gets fixed upstream. Applied this to the Debian BZR repository of CUPS so that the fix will appear in the next CUPS package for Precise and also applied to a Stable Release Update (SRU) CUPS package for Oneiric which I have uploaded to -proposed. As soon as this package gets approved and ready for testing on Oneiric, a separate comment with testing instructions will get posted here. Please test the package then and report back here, so that we can make it an official update.

A debdiff of the SRU for Oneiric is attached.

Robert Bradley, thank you for all the work on these bugs and the downgrade patch for the IPP backend.

This bug was fixed in the package cups - 1.5.0-13

---------------
cups (1.5.0-13) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/patches/ipp-patch-r8950+.patch: Revert the IPP backend to the state
    of CUPS 1.4.x, as the 1.5.x versiuon has major regressions (LP: #877958,
    LP: #879625, LP: #881843, LP: #883585, Closes: #638521, CUPS STR #3966,
    CUPS STR #3967). This patch will get removed as soon as upstream has fixed
    all these regressions. As upstream did not announce any new features for
    the IPP backend in the release notes for 1.5.x, we assume that with this
    step no features will get lost.
  * debian/patches/dont-send-malformed-dbus-messages.patch: Do not send D-Bus
    notifications with too few parameters when there are parameters which
    cannot be added to the D-Bus request, especially invalid UTF-8 strings.
    This made gnome-session-daemon crash (LP: #893676, CUPS STR #3984).
  * debian/local/filters/cpdftocps: The cpdftocps filter (used for PostScript
    printers and for drivers with PPDs which are not PDF-aware) did not
    recognize the duplex setting correctly, making duplex not working on
    many common printers (LP: #897723).
  * debian/local/filters/cpdftocps: Cleaned up the header comments.

  [ Martin-Éric Racine ]
  * [cups.postrm]: purge /etc/cups/ssl/server.[crt|key] and /etc/cups/ssl.

  [ Martin Pitt ]
  * debian/compat: Bump from 5 to 9, this apparently was forgotten in the
    Multi-Arch transition.
 -- Martin Pitt <email address hidden> Fri, 02 Dec 2011 11:05:51 +0100

Hello Tim, or anyone else affected,

Accepted cups into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

For me it's OK : applying the package-update cups - 1.5.0-13 (from the
proposed repository) make my printer work again.
Good job!
Thanks!

Le 05/12/2011 07:15, Martin Pitt a écrit :
> Hello Tim, or anyone else affected,
>
> Accepted cups into oneiric-proposed, the package will build now and be
> available in a few hours. Please test and give feedback here. See
> https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
> enable and use -proposed. Thank you in advance!
>
> ** Tags added: verification-needed
>

mavosaure, thank you very much for testing. Marking the bug as verified.

Hi,
I tested the new package-update of cups for my Canon MP240 plugged on a Linksys Switch Print Server PSUS4. And it works perfectly : until now, I hadn't succeeded to print with any earlier version of Ubuntu (the first page stayed blocked).
So for me, now it's an improvement (no more regression like until now).
I'm going to test at home with my Livebox and my Canon iP4500 and I tell you if it works too.

I have filed three new bugs upstream now for these issues. This is deliberate since I know upstream are reluctant to work around every possible print server bug from last time.

http://www.cups.org/str.php?L3986:

This is the original bug regarding Novell print servers, and the patch is the same as in comment #12 here.

http://www.cups.org/str.php?L3987:

This covers the remainder of the patches here, and attempts to sort out the Livebox2 issues. As disabling chunking is seen as a large change to work around one printer server's bugs, this is unlikely to be accepted upstream unfortunately. Does anyone know if OS X Lion compatibility has been filed as an issue with Orange France or Sagem?

http://www.cups.org/str.php?L3988:

This is the bug where print data can be lost if the print server does not support HTTP 1.1 (fixed in comment #46 here). I separated this bug out since this is a true (if rarely triggered) bug in upstream, as opposed to a workaround for print server bugs. This may well get fixed, but will achieve nothing for Livebox2 users without the chunking patches being included too.

Hi,
I tested the new package-update of cups with my Canon Pixma iP4500 plugged on the Livebox2 router. And now, I can print via wifi like before under Ubuntu 10.10 .
So for me, the bug is fixed.
I thank everybody especially Robert Bradley for this patience and perseverance.
Regards

Thierry, also thank you for doing all the testing and supplying all the information for working on this bug.

This bug was fixed in the package cups - 1.5.0-8ubuntu6

---------------
cups (1.5.0-8ubuntu6) oneiric-proposed; urgency=low

  * debian/patches/ipp-patch-r8950+.patch: Revert the IPP backend to the state
    of CUPS 1.4.x, as the 1.5.x versiuon has major regressions (LP: #877958,
    LP: #879625, LP: #881843, LP: #883585, Closes: #638521, CUPS STR #3966,
    CUPS STR #3967). This patch will get removed as soon as upstream has fixed
    all these regressions. As upstream did not announce any new features for
    the IPP backend in the release notes for 1.5.x, we assume that with this
    step no features will get lost.
  * debian/patches/dont-send-malformed-dbus-messages.patch: Do not send D-Bus
    notifications with too few parameters when there are parameters which
    cannot be added to the D-Bus request, especially invalid UTF-8 strings.
    This made gnome-session-daemon crash (LP: #893676, CUPS STR #3984).
  * debian/local/filters/cpdftocps: The cpdftocps filter (used for PostScript
    printers and for drivers with PPDs which are not PDF-aware) did not
    recognize the duplex setting correctly, making duplex not working on
    many common printers (LP: #897723).
  * debian/local/filters/cpdftocps: Cleaned up the header comments.
 -- Till Kamppeter <email address hidden> Tue, 29 Nov 2011 21:49:41 +0100

I had the same problem on suse 12.1.
I installed cups 1.5.2 but tht did not resolved the problem.

I was using a livebox with ipp://192.168.1.1:631/ipp on a HP laserjet printer. I always got the same message :
printfile was not accepted.
I expected that the new cups version take into account the patch. Must i wait for another cups update ?

many thanks

Moreau, please report your problem at SUSE then.

Yes already done, they sent me to cups, i want to mentioned that apparently CUPS 1.5.2 did not incorporate the patch discussed here.

Thanks for your remark

I collected this report on cups.org :
http://www.cups.org/str.php?L3986

I am not sure to clearly understand, but does that mean that they wont take into account that problem ?

Many thanks for your advices

SM