Bug 2263053 - CUPS/libppd PPD generators didn't check required attrs when deciding which driverless format to use, causing PPD generation to fail
Summary: CUPS/libppd PPD generators didn't check required attrs when deciding which dr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libppd
Version: 39
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-02-06 19:28 UTC by Jason Tibbitts
Modified: 2024-03-03 01:36 UTC (History)
1 user (show)

Fixed In Version: libppd-2.0.0-4.fc39 libppd-2.0.0-4.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-02-25 01:25:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Some debug logging (28.22 KB, text/plain)
2024-02-06 19:33 UTC, Jason Tibbitts
no flags Details
Perhaps more useful information (44.65 KB, text/plain)
2024-02-06 19:51 UTC, Jason Tibbitts
no flags Details
testing rpms (5.60 MB, application/gzip)
2024-02-09 06:50 UTC, Zdenek Dohnal
no flags Details

Description Jason Tibbitts 2024-02-06 19:28:46 UTC
Please forgive me if I've chosen the wrong component; this was where my previous driverless printing issue ended up.

I am trying to configure a new Brother HL-L9410CDN color printer.  (I tend to use system-coinfig-printer to do this.)  Driverless printing does appear to be supported, but after choosing the following for the driver:

"Brother HL-L9410CDN series, driverless, cups-filters 2.0.0 [en] (recommended)"

I get an error "There was an error during the CUPS operation: 'server-error-internal-error'.

Checking the logs, I see the following:

cupsd[302289]: Printer "rm691-color" modified by "root".
cupsd[302289]: REQUEST localhost - root "POST /admin/ HTTP/1.1" 200 174 CUPS-Add-Modify-Printer successful-ok
cupsd[302289]: [CGI] Unable to create PPD file: Printer does not support required IPP attributes or document formats.
Feb 06 13:17:35 print1.e.math.uh.edu cupsd[302289]: [Client 7912023] Returning IPP server-error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost/printers/rm691-color) from localhost.
cupsd[302289]: REQUEST localhost - root "POST /admin/ HTTP/1.1" 200 235 CUPS-Add-Modify-Printer server-error-internal-error

I'm not sure how to get the printer to tell me what it supports so I can provide that information.  I cranked the CUPS debugging up to high and captured what I think is the relevant information; my print server is quite active so there may be some cruft in there.  I will attach what I have.

Reproducible: Always

Steps to Reproduce:
Try to configure driverless printing for a Brother HL-L9410CDN.
Actual Results:  
Get a cups internal error.

Expected Results:  
Printing is configured correctly.

python3-cups-2.0.1-18.fc39.x86_64
libcupsfilters-2.0.0-2.fc39.x86_64
cups-filters-2.0.0-1.fc39.x86_64
cups-pk-helper-0.2.7-4.fc39.x86_64
cups-libs-2.4.7-5.fc39.x86_64
cups-filesystem-2.4.7-5.fc39.noarch
cups-client-2.4.7-5.fc39.x86_64
cups-2.4.7-5.fc39.x86_64
cups-browsed-2.0.0-1.fc39.x86_64
cups-ipptool-2.4.7-5.fc39.x86_64
libppd-2.0.0-1.fc39.x86_64

Comment 1 Jason Tibbitts 2024-02-06 19:33:53 UTC
Created attachment 2015425 [details]
Some debug logging

Comment 2 Jason Tibbitts 2024-02-06 19:51:48 UTC
Created attachment 2015428 [details]
Perhaps more useful information

I noticed a specific command in the previous debug log and so I went ahead and did some experimentation with that directly.  I ended up running:

# /usr/lib/cups/daemon/cups-driverd cat driverless:ipp://printer-color-691/ > /tmp/foo2 2>&1

which gave what appears to be more useful output (attached).

Comment 3 Zdenek Dohnal 2024-02-07 06:40:55 UTC
Hi Jason,

there is a documentation for this (I wrote contents, Brandon Nielsen converted it to ASCII doc) - https://docs.fedoraproject.org/en-US/quick-docs/cups-debug-printing-issues/#_driverless_models .

The documentation contains even useful tricks etc., it is a good place to start when printing does not work.

The last file contains IPP attributes - I see the device shows AirPrint support (image/urf as document format means AirPrint):

DEBUG2:   Attr: document-format-supported
DEBUG2:   Value: application/octet-stream,image/urf,image/jpeg,image/pwg-raster

but no urf-supported attribute.

This results in the error in ppdCreatePPDFromIPP2(), because the function sets `formatfound` to 1 only if `urf-supported` exists if the device supports `image/urf` format.


Jason, are you sure that you enabled AirPrint on the device - or any IPP Everywhere or similar settings? Look into its web interface via web browser (available on the printer's ip address, which I can't tell you, since you obfuscated the logs :) - but in case it is IPP-over-USB device, web interface is on localhost:60000) or into settings on printer panel/touchpad.

I had a similar case in the past (thanks oholy! :) ), and the problem was that AirPrint was disabled on the device.

Comment 4 Zdenek Dohnal 2024-02-07 06:44:32 UTC
If that's the real issue, you have mDNS enabled on the printer and don't want to share the printer further, then you won't need to install the printer at all - you can use temporary queue via CUPS itself. The print queue will appear once you want to print and then disappear when not needed.

Comment 5 Jason Tibbitts 2024-02-07 18:20:49 UTC
So as to not bury the important info, I turned airprint back on and was able to generate a useful PPD which I think prints correctly.  (I am not in the office today but I can send a job and it does seem that the printer does what it should; I just can't see the output.)

In case this detail matters, we have a central print server that is the only thing that can talk to the printers (throughout our medium-size university department).  So I'm adding a queue on that central server that will be visible to the 200 or so Linux machines on our network, plus a bunch of Windows using the CUPS driver and various apple machines.

Apple-specific things like airprint are usually the first things I turn off, since I just want printing for our central print server and the printer's internal firewall is set up to prevent connections from other machines anyway.  I have not previously known that that functionality is somehow related to normal printing functions.  Currently I have IPP enabled, and both AirPrint and Mopria (whatever that is) disabled.  I guess that's either not a reasonable configuration, or that it causes the printer to send confusing or broken information, or that it just tickles a bug somewhere in CUPS.

I certainly did not intend to obfuscate the logs; what I sent was the full output of the command I gave, and the full output of journalctl --no-hostname -u cups trimmed to the time range where I tried to create the printer.  If it's important, the address is 172.21.86.57 though of course that's not a public address.  

I ran the ipptool and driverless commands suggested in the document you linked; the latter appears to give exactly what I already pasted.  I can attach the ipptool outpout (with airprint disabled, or enabled) if that is useful.

Finally, what seems interesting to me is that the printer is supposed to be postscript (and PDF) compatible but I'm not sure where it indicates that.  Is CUPS having to rasterize the output on the server to send to the printer?

Comment 6 Zdenek Dohnal 2024-02-08 09:58:46 UTC
(In reply to Jason Tibbitts from comment #5)
> So as to not bury the important info, I turned airprint back on and was able
> to generate a useful PPD which I think prints correctly.  (I am not in the
> office today but I can send a job and it does seem that the printer does
> what it should; I just can't see the output.)

Good to know! Let me know once you are in the office and know the result of the test! :)

> 
> In case this detail matters, we have a central print server that is the only
> thing that can talk to the printers (throughout our medium-size university
> department).  So I'm adding a queue on that central server that will be
> visible to the 200 or so Linux machines on our network, plus a bunch of
> Windows using the CUPS driver and various apple machines.

Ok, so you can't use the temporary queue - you have to share the queue in this case, which cannot be done with temporary queue.

> 
> Apple-specific things like airprint are usually the first things I turn off,
> since I just want printing for our central print server and the printer's
> internal firewall is set up to prevent connections from other machines
> anyway.  I have not previously known that that functionality is somehow
> related to normal printing functions.

Printer has to support a driverless standard if you want to print/install the printer without classic driver - AirPrint and Mopria are driverless standards, so unless the device does not support other driverless standard internally, without any option to turn it on/off, one of them has to be enabled for printer to work driverlessly.

However, I've checked your last file and it looks like your device can support IPP Everywhere (another driverless standard), because I see all IPP attributes we need in PPD generation to be present. In CUPS and cups-filters we currently prefer AirPrint if the device supports document format associated with it - image/urf - which your printer does with AirPrint disabled, and don't check for other driverless support if we found image/urf. It is because it gives better printing results (it creates raster file, which is sent to the device - PDF printing sometimes can end up with garbled fonts, if the device does not support them and they are not taken care of during filtering...). We could IMHO try other driverless standards if there is image/urf and no urf-supported - I've implemented it in the build lower.

I have created patched CUPS build - https://koji.fedoraproject.org/koji/taskinfo?taskID=113141324 - which should check for urf-supported together with image/urf, and if not found, look for other driverless standard - it might get your device working even without enabling AirPrint, if IPP Everywhere support is in place and functional.

Just install the printer via f.e. lpadmin with '-m everywhere':

$ lpadmin -p <queue_name> -v ipp://<printer-ip>/ipp/print -m everywhere -E

> I certainly did not intend to obfuscate the logs; what I sent was the full
> output of the command I gave, and the full output of journalctl
> --no-hostname -u cups trimmed to the time range where I tried to create the
> printer.  If it's important, the address is 172.21.86.57 though of course
> that's not a public address.

Aha, I thought you did some obfuscation because the URI is ipp://printer-color-691/ - it looked like placeholder for real IP/hostname, which is sometimes important to know whether the device is connected via network, or via USB and it is advertised by ipp-usb HTTP proxy (approx 10 years old printers can be supported like this).
 
> 
> I ran the ipptool and driverless commands suggested in the document you
> linked; the latter appears to give exactly what I already pasted.  I can
> attach the ipptool outpout (with airprint disabled, or enabled) if that is
> useful.

I was able to figure out thing from the current files, so the document is just for future reference, so you don't need to run cups-driverd or cups-deviced helper binaries - which can bring a different kind of errors :) .

> 
> Finally, what seems interesting to me is that the printer is supposed to be
> postscript (and PDF) compatible but I'm not sure where it indicates that. 
> Is CUPS having to rasterize the output on the server to send to the printer?

IPP attribute 'document-format-supported' lists all document formats which printer accepts via IPP port - application/octet-stream usually means raw file printing, which might mean any file which printer is able to process (might be even postscript or PDF). Or Postscript interpret lies on a different printer's port, like 9100.

Comment 7 Zdenek Dohnal 2024-02-09 06:21:11 UTC
Please test the package today or in next two days - the scratch build is available only for several days, and I would have to create a new one if it disappears before you test it.

Comment 8 Zdenek Dohnal 2024-02-09 06:50:09 UTC
Created attachment 2016000 [details]
testing rpms

Just in case attaching the testing rpms.

Comment 9 Jason Tibbitts 2024-02-13 00:38:44 UTC
I had done koji download-task 113141324 so I had a copy of the packages, though scratch builds are kept around for at least a week these days.  (It used to be 14 days but I suppose that might have changed.)

I can run the lpadmin command you provided (lpadmin -p test1 -v ipp://printer-color-691/ -m everywhere -E) without error, and the queue is usable.  Honestly I've not set up a queue with lpadmin like that and have always used system-config-printer to set things up.  And I do note that when I try to use system-config-printer to add a queue, I get the same error as before with this logged:

Feb 12 18:13:22 cupsd[728316]: [CGI] Unable to create PPD file: Printer does not support required IPP attributes or document formats.
Feb 12 18:13:22 cupsd[728316]: copy_model: empty PPD file
Feb 12 18:13:22 cupsd[728316]: [Client 9262] Returning IPP server-error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost/printers/rm>
Feb 12 18:13:22 cupsd[728316]: REQUEST localhost - root "POST /admin/ HTTP/1.1" 200 314 CUPS-Add-Modify-Printer server-error-internal-error

Obviously whatever method system-config-printer uses does something different than lpadmin.  When it works (via lpadmin) I just get this:

Feb 12 18:17:08 cupsd[728316]: REQUEST localhost - root "POST /admin/ HTTP/1.1" 200 276 CUPS-Add-Modify-Printer successful-ok
Feb 12 18:17:22 cupsd[728316]: REQUEST localhost - - "POST /admin/ HTTP/1.1" 401 0 - -

Comment 10 Zdenek Dohnal 2024-02-13 07:17:30 UTC
system-config-printer does not support everywhere model, only driverless model - each of them has a separate PPD generator from separate packages - cups and cups-filters. I've made the change in CUPS for now, but I can share the patch to cups-filters as well.

I highly recommend being on site with the printer or collaborate with someone close by to the printer when you test whether printing works - until the paper comes out of the device, I wouldn't call it successful testing :D .

Personally I prefer working on and using CUPS CLI and CUPS web interface, even though I'm system-config-printer's maintainer and upstream as well. In case you like to use system-config-printer and want to improve it/update it, upstream developers are more than welcome :)

Comment 11 Zdenek Dohnal 2024-02-13 07:39:56 UTC
Patches sent upstream for review:

CUPS:
https://github.com/OpenPrinting/cups/pull/890

libppd:
https://github.com/OpenPrinting/libppd/pull/39

Comment 12 Jason Tibbitts 2024-02-13 21:44:51 UTC
I had no idea that system-config-printer did not work via the same internal mechanism.  That means that I really should try both if I run into any issues.

And yes, I did go over to the printer and make sure that it was able to print some test pages and jobs.  It appears to be working just fine.

Comment 13 Fedora Update System 2024-02-16 09:47:57 UTC
FEDORA-2024-39d808370c (libppd-2.0.0-4.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-39d808370c

Comment 14 Fedora Update System 2024-02-16 09:57:04 UTC
FEDORA-2024-478c7ebee1 (libppd-2.0.0-4.fc38) has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-478c7ebee1

Comment 15 Fedora Update System 2024-02-16 10:27:22 UTC
FEDORA-2024-9314f58648 (cups-2.4.7-11.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-9314f58648

Comment 16 Fedora Update System 2024-02-16 11:32:51 UTC
FEDORA-2024-956a46e5dd (cups-2.4.7-11.fc38) has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-956a46e5dd

Comment 17 Fedora Update System 2024-02-17 01:57:37 UTC
FEDORA-2024-478c7ebee1 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-478c7ebee1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-478c7ebee1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2024-02-17 01:57:40 UTC
FEDORA-2024-956a46e5dd has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-956a46e5dd`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-956a46e5dd

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 19 Fedora Update System 2024-02-17 02:05:10 UTC
FEDORA-2024-39d808370c has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-39d808370c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-39d808370c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 20 Fedora Update System 2024-02-17 02:05:14 UTC
FEDORA-2024-9314f58648 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-9314f58648`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-9314f58648

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 21 Fedora Update System 2024-02-25 01:25:06 UTC
FEDORA-2024-39d808370c (libppd-2.0.0-4.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 22 Fedora Update System 2024-02-25 01:25:11 UTC
FEDORA-2024-9314f58648 (cups-2.4.7-11.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 23 Fedora Update System 2024-02-25 01:25:14 UTC
FEDORA-2024-478c7ebee1 (libppd-2.0.0-4.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 24 Fedora Update System 2024-03-03 01:36:31 UTC
FEDORA-2024-956a46e5dd (cups-2.4.7-11.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


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