PJL output from 1.2.2 client over IPP

Thanks for your bug report.
Please provide more details about your setup.
Do you try to print from Windows to an Ubuntu print server or from anthor Ubuntu or Linux machine? Are both the print server and client CUPS version 1.2.2?

Please attach the output of the printingbuginfo script for both print server and client, read more here: https://wiki.ubuntu.com/PrintingBugInfoScript

The print server is running Debian Sarge. The client is Ubuntu Breezy. The Debian print server is running cupsys 1.1.23-10sarge1.

I'm experimenting the same problem: I'm printing to a Hp DeskJet 1120C over IPP to a remote cupsys print serve, once I installed 1.2.2-0ubuntu0.6.06 all print jobs come out just as PCL code, e.g. this is the result of printing the test page:

-12345X@PJL ENTER LANGUAGE=PCL3
17H0M126AoM1-2Hu300D10L148D14E16Dp0x26WXX,,,,,,r1Ab2Mp189Yb602V

The print server I'm printing to is running, as the client (a laptop) experimenting the problem, Ubuntu Linux 6.06; both run CUPS version 1.2.2. Printing directly from the server works fine, as printing from a Windows client. Printing from other ubuntu clients (CUPS 1.2.2-0ubuntu0.6.06) doesn't work.

@Marco
Did you run the script on your laptop or print server?
The output shows you have a direct connected printer on LPT1, on the client I would expect a device with an ipp address.
Can you run the script on your laptop.

@Pascal
Sorry, I run the script on my laptop, but I forgot to remove the client.conf (in /etc/cups/) I used as a quick fix to the problem. Specifying in client.conf the line

ServerName <myprintservername>

I am avoiding the local spooling, which seems affected by the problem reported.
Now I've run the script with the configuration (client.conf removed) actually experimenting the problem. It shows correctly device with an ipp address.

This thred http://ubuntuforums.org/showthread.php?t=232996 (on the ubuntu-users malinglist) describes the same problem reported here.

Thanks for your bug reports,
I can reproduce the problem with my HP DeskJet 3820 printer connected to a Debian Sarge print server (cupsys 1.1.23-10sarge1) and Ubuntu Dapper 6.06 LTS (cupsys 1.2.2-0ubuntu0.6.06) used as print client.

I have found that setting up a raw queue printer on the server works without problems. In CUPS web interface or gnome-cups-manager this can be done by selecting Manufacturer: Raw and Model: Queue. Let me know if this works for you.
This is a better solution than using ServerName in client.conf.
I don't know if this is a bug or perhaps a change made in 1.2.2 to use server side drivers.

Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382936.

So the "raw" queue should be on the server?

I don't get it, the Debian Sarge server (in our case) has been configured for the particular printer we use along with PPD files and whatnot. The server works fine.It definitely wasn't trivial to get it all going as CUPS is quite hard to set up and I'm not going to break the server's fragile configuration just because some Kubuntu CUPS package is broken.

Currently we can print to the perfectly working server from our Mac, I will not break that last way of printing (on Linux we print to a file, switch to the Mac and then print the file...)

I'm sorry if this sounds negative, but we initially spent literally days trying to work around the badly configured CUPS packages in order to get stuff to work, I'm not going to break that configuration.

client = dapper ; cupsys 1.2.0
server = hoary ; cupsys_1.1.23; HP Deskjet 3745
I had been using cupsys 1.2.0 as 1.2.2 would only print "$$" when printing anything from a client machine to the server. I set the Manufacturer: Raw and Model: Queue as per above. This didn't print anything at all but when re-setting the Manufacturer: HP and Model: Deskjet 3745 and upgrading to cupsys 1.2.2 on the client it worked! Very strange ...

Rob Steele wrote:
> Thanks Pascal! That was a big help. The raw queue works great
> for me.

> I also discovered that if I enable browsing on my Dapper client, I
> can use the printer that was found by browsing and it also
> works fine, no problems. The "browsed-to" printer must also use
> server-side drivers, since I cannot set any driver information on
> the client this way (it is disabled in the UI).

Thanks for the info Rob.
I think I understand the problem now.

Forget about the workaround I mentioned before by setting up a raw queue on the server.

When setting up an IPP printer with gnome-cups-manager on a print client you always have to associate a PPD with it by selecting the manufacturer, model and driver for your printer.
This doesn't make sense for a network printer, since you have already configured the manufacturer, model and driver on the print server.

To make it work you can setup your printer manually with the following command:
$ lpadmin -p printername -E -v ipp://10.0.0.40/printers/dj3820

Another possibilty is to activate browsing on the server to let your print client autodetect the printers.
You can easily enable browsing on an Ubuntu print server by running the following command:
$ sudo /usr/share/cups/enable_browsing 1
Then start gnome-cups-manager on the print client an activate Global settings > Detect LAN printers. Now wait 30 seconds and your printers will appear.

In both cases you will see that the "Paper" and "Advanced" tabs are disabled in the "Properties" of you printer in gnome-cups-manager, this is normal.

Associating a PPD with an IPP printer with gnome-cups-manager worked in CUPS 1.2.0 and 1.2.1, this behaviour seems to have changed in CUPS 1.2.2.
This could be a bug in CUPS 1.2.2, but IMHO setting up an IPP printer associated with a PPD file doesn't make sense since you already configured the printer on the server. Therefore gnome-cups-manager should be altered so it doesn't ask the manufacturer, model and driver for an IPP printer.
Also printing options should be visibile in the "Paper" and "Advanced" tab of the printer "Properties". These options should be read from the server which is perfectly possible now from the following command line:
$ lpoptions -d printername -l
These printer options are set on the server but gnome-cups-manager should allow for an override on the client in ~/.cups/lpoptions.

@Jan

> So the "raw" queue should be on the server?

No, as described above there is a better solution which does NOT involve changes to the server.
But for Kubuntu Dapper you could use the KDE config tools, if you work around the problem described below.

In Kubuntu Dapper you should manually merge the content of /etc/cups/cups.d/browse.conf and ports.conf into /etc/cups/cupsd.conf for the KDE config tools to work.
Strangely enough the Dapper cupsys package 1.2.2-0ubuntu0.6.06 doesn't have this change while this is already fixed in edgy (see below).

cupsys (1.2.2-0ubuntu1) edgy; urgency=low

  * Merge to Debian unstable:
    - This gets rid of /etc/cups/conf.d/ again and re-merges the separate browsing and ports settings to /etc/cups/cupsd.conf again. Separating was nice for preserving an unchanged conffile for the most important settings, but it broke KDE and the web interface and generated way too many bugs.

 -- Martin Pitt <email address hidden> Mon, 24 Jul 2006 11:20:04 +0200

After this you should be able to setup your network printer on the client without problems.
If it still doesn't work with the KDE config tools you can always try this command:
$ lpadmin -p printername -E -v ipp://10.0.0.40/printers/dj3820
You just need to adjust this with the IP address of your print server and your printer name.

Please try the above and let me know if it works.

Well, that did exactly the same as before.

I merged /etc/cups/cups.d/browse.conf and ports.conf into /etc/cups/cupsd.conf, commented out the data in those two files and restarted cups. I tried to create a new printer using the KDE printer manager (ipp://server:631/printers/printername), selected the correct model and gave it the correct PPD file (from /etc/cups/ppd/) but it does exactly the same. Prints a few lines of garbage.

I also tried the lpadmin way and that produced a printer that at least can print, but somehow broke all admin interfaces on the two Dappers.

Now, when I try to check out http://localhost:631 and view my printers I just get a page with "Bad request" where the printers should be, so now it's more broken than before. Trying to rename the printer with the KDE printer tool gives me a simple error dialog with: "Unable to change printer properties. Error received from manager: client-error-not-found". No sane information is shown about the printer either, it is recognized as a "Local printer" insted of an ipp:// printer as it should be.

Pascal, thanks a lot for your patient help. I think we just need to wait for the CUPS folks to fix the bugs and then I probably need to reinstall the systems in order to get it working as it should. This should teach me to blindly apply package upgrades. :(

> I merged /etc/cups/cups.d/browse.conf and ports.conf into
> /etc/cups/cupsd.conf, commented out the data in those two
> files and restarted cups. I tried to create a new printer using
> the KDE printer manager
> (ipp://server:631/printers/printername), selected the correct
> model and gave it the correct PPD file (from /etc/cups/ppd/)
> but it does exactly the same. Prints a few lines of garbage.

Does KDE printer manager ask for a PPD when setting up a network printer? As explained above the problem is that network printers normally don't need a PPD!

> I also tried the lpadmin way and that produced a printer that at > least can print, but somehow broke all admin interfaces on the
> two Dappers.

> Now, when I try to check out http://localhost:631 and view my
> printers I just get a page with "Bad request" where the printers
> should be, so now it's more broken than before.

This is probably bug #42513, which was fixed in cupsys 1.2.2-0ubuntu0.6.06. You probably did a downgrade to 1.2.0.
Please make sure you have cupsys 1.2.2-0ubuntu0.6.06.

> Trying to rename the printer with the KDE printer tool gives me > a simple error dialog with: "Unable to change printer
> properties. Error received from manager:
> client-error-not-found". No sane information is shown about
> the printer either, it is recognized as a "Local printer" insted of >an ipp:// printer as it should be.

KDE 3.5.2 print manager is broken when used with CUPS 1.2 due to KDE 3.5.2 using private CUPS API, more info here: http://www.kdedevelopers.org/node/1901.

> Pascal, thanks a lot for your patient help. I think we just need
> to wait for the CUPS folks to fix the bugs and then I probably > need to reinstall the systems in order to get it working as it
> should. This should teach me to blindly apply package
> upgrades. :(

Please don't blame the wrong people here. The problems are caused by KDE, Mike Sweet has informed the KDE people in advance and they haven't dealt with the problem when it was there. In the meanwhile the problem has been fixed but you will have to wait for Edgy to see these fixes.

But you should be able to use your printer with the CUPS web interface in KDE 3.5.2 and lpadmin as described above to setup your IPP printer!

This is:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201167

and

http://www.easysw.com/~mike/cups/str.php?L1881+P0+S-2+C0+I10+E0+Q

Mike has patch for this, but it needs testing. It will be applied as soon as it proofs to be OK. Patch can be found at:

http://www.easysw.com/cups/newsgroups.php?s2026+gcups.commit+v2032

Here I'm talking about TWO Fedora Core 5 recent, clean installs... Both of them up to dated; CUPS v.1.2.2; repos from Core, Extras and Livna, stable rpms (no testing). Gnome desktop, my choice.
Printer an HP 5150 deskjet, attached to my desktop PC, this is the printing server. I'd like to be able to print from my laptop via IPP. Both, desktop and laptop PCs conforms a LAN with assigned static IPs. Both of systems with its firewall configured (Firestarter GUI) widely permissive in order to be sure it's not interfering: allowing connections from respective hosts, opened 631 and 515 ports.
Printing server configured graphically through gnome applet, Sharing local printer, allowing connexions from any IP from the LAN, etc... (being a really generous setup).
Printing client configured via IPP pointing against the server IP/printers/name.of.the.queue
A similar scenario did work perfectly before, when both systems were with FC4 installed.
No doubts here: printer has no fault, neither hw nor configs, since it works perfectly from any direct connection.
Trying to print from the client (laptop) it only gives this message:

Message:

-12345X@PJL ENTER LANGUAJE=PCL3GUI
17H1-1M126Ao0M1-2Hg20WXX XX
u600Dr48....etc...

Could you add:

deb http://www.grad.hr/~ivoks/ubuntu/cups ./

to /etc/apt/sources.list, run 'sudo apt-get update ; sudo apt-get upgrade' and test printing?

I'm attaching debdiff of changes.

Thanks

Ups... :) Sorry about that; here's the better debdiff

Joy!

Upstream has a solution, but before we upload this packages to dapper-updates, I would like you to test them first and observe if there are any side effects. Packages can be downloaded if you put:

deb http://www.grad.hr/~ivoks/ubuntu/cups ./

in /etc/apt/sources.list and run 'sudo apt-get update ; sudo apt-get upgrade'.

debdiff is provided (ignore all before this one).

@Ante
I tested the Upstream update, and for me it's ok. Now, on the client, both the printer configured with the raw driver and the one with the DeskJet driver work fine. On the client I am running Ubuntu Dapper, the same on the server.

I use a printing server at the router, the router is a US Robotics 9108A. The printer is a Samsung ML-1610, USB printer.

I've been reading other posts before reporting so I tried also the repository at:

deb http://www.grad.hr/~ivoks/ubuntu/cups ./

I tested with dapper and edgy and neither of them makes it work. With a raw printing, with a samsung ppd and with cupsys ppd ML-1510. No luck neither.

my clean dapper on a new laptop was not printing to a gentoo cups server
(hplj4l) that worked fine before (also for osx, winxp, etc.). Problem as
noted above re a few lines of control commands then nothing. My fix
was to enable browsing on client then use one of the browsed printers
for default. I manually setup browsing on my client by modifying
/etc/cups/cups.d/browse.conf:

Browsing On
BrowseProtocols cups
BrowseAddress 192.168.12.255
BrowseShortNames Yes
BrowseAllow All
BrowseDeny None
BrowseInterval 30
BrowseOrder allow,deny
BrowsePort 631

If you use this change the browse address for your network setup.

I tried with my Ubuntu dapper, and it didn't worked out. With a raw printing, with a postscript ppd and with cupsys ppd ML-1510.

@Robert Casanova
I have reopened your original bug #57822. Please post further comments related to your problem there.

Fixed in dapper.

Erm, sorry, that previous comment should have read 'Fixed in edgy'.

Adding dapper task.

Assigning to me for the next dapper cups update.

Matt, ok to apply this upstream svn commit (from 1.2.3) to dapper? (Upgrading dapper to 1.2.3 is not advisable ATM since it has some regressions).

On Mon, Sep 11, 2006 at 03:26:32PM -0000, Martin Pitt wrote:
> Matt, ok to apply this upstream svn commit (from 1.2.3) to dapper?
> (Upgrading dapper to 1.2.3 is not advisable ATM since it has some
> regressions).

The standing policy is that only high-impact bugs are subject to
backporting, and there is a moratorium on non-security updates while the
policy is formalized.

--
 - mdz

Rejecting dapper task, since it does not fit https://wiki.ubuntu.com/StableReleaseUpdates conditions.

I don't undestand how this doesn't fit the second criteria "Bugs which represent severe regressions from the previous release of Ubuntu".

The previous package in Dapper worked and a subsequent upgrade broke printing. (I am reporter of bug 57706 which was marked a duplicate of this one)

Francis: Ok, I missed the fact that this was a dapper->dapper-updates regression, sorry.

Martin,

Any news on this? I have just been bitten by it as well.

Martin,

Any news?

Adjusted latest debdiff to use "-proposed".

Kees,
The bug number mentioned in your changelog should be #55828 instead of #55282.

Sorry, this has fallen off my table, I'll deal with it now.

SRU justification: This bug is a regression in a dapper-updates upload, affects many users, and has a trivial patch that is contained in upstream releases, edgy, and Feisty.

 status fixcommitted

I fixed the changelog of Ante's debdiff to comply to SRU policy and
fixed the bug number. Patch looks good, uploaded to dapper-updates.

This is now ready for QA testing.

Thanks,

Martin

Sorry, the email command changed the wrong task.

Can you guys please test the current dapper-proposed version and give some feedback here? Thank you!

This has been fixed upstream a long time ago.

With dapper, I now get this:

[16/Feb/2007:10:18:30 -0800] cupsdAuthorize: Local authentication certificate not found!
E [16/Feb/2007:10:18:30 -0800] cupsdAuthorize: Local authentication certificate not found!
...
repeated endless until I cancel the print job

I also get this:

Paused: /usr/lib/cups/backend/ipp failed

Corey, hmm, that does not look at all like a consequence of that patch. This needs closer investigation. Till, any advice how to debug this?

Yes, I realize that. But I have two basically identical machines, one with this patch and one without. They both print to an FC4 machine that is the print server. The unpatched one spits out this bug. The patched one spits out the above. I am trying to debug further.

This was also reported as Debian bug #382936. We would appreciate feedback from Ubuntu users to confirm whether we can close this bug in Debian.

@Martin-Éric Racine

I can confirm this bug got resolved on Ubuntu.

Can anyone please test the package in -proposed and report back? When we get positive results, I consider this for the pending dapper point release.

There are so many duplicates to this bug, that there just has to be *someone* who still uses a printer which is affected by this bug. Can anyone please test the packages in dapper-proposed and report back? Thank you in advance!

If bug #57822 is a duplicate, I just posted new comments there. But seeing Pascal's comment on 2006-08-30, https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/55828/comments/26 it is probably not, is it?

This got superseded by other SRUs in dapper. Since nobody provided successful feedback, and there was very little feedback at all, I close this SRU.