Canon PIXMA MX925: "lpadmin -p testq ... -m everywhere" returns "Unable to create PPD file: No such file or directory"

[jaimet]

Debian stable (bullseye), v11.3

$ ippfind
ipp://inkjet.local:631/ipp/print

$ sudo lpadmin -p testq -v ipp://inkjet.local:631/ipp/print -E -m everywhere
lpadmin: Unable to create PPD file: No such file or directory

I don't understand much about cups and IPP, so I'm not sure whether this is a bug, whether it's "by design" (the Canon PIXMA MX925 is not in the list at https://www.pwg.org/printers/ so perhaps this command is supposed to fail), and even if this is a bug, whether or not this is the correct place to report it.

Preemptively I am attaching the outputs from:

ipptool --ippserver printer.attr.txt ipp://inkjet.local:631/ipp/print get-printer-attributes.test
printer.attr.txt

and

driverless ipp://inkjet.local:631/ipp/print > ppdProducedByDriverless.ppd
ppdProducedByDriverless.ppd.txt

FWIW,

$ dpkg -l | grep -i cups
ii  cups                        2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - PPD/driver support, web interface
ii  cups-client                 2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - client programs (SysV)
ii  cups-common                 2.3.3op2-3+deb11u2             all          Common UNIX Printing System(tm) - common files
ii  cups-core-drivers           2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - driverless printing
ii  cups-daemon                 2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - daemon
ii  cups-filters                1.28.7-1+deb11u1               amd64        OpenPrinting CUPS Filters - Main Package
ii  cups-filters-core-drivers   1.28.7-1+deb11u1               amd64        OpenPrinting CUPS Filters - Driverless printing
ii  cups-ipp-utils              2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - IPP developer/admin utilities
ii  cups-ppdc                   2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - PPD manipulation utilities
ii  cups-server-common          2.3.3op2-3+deb11u2             all          Common UNIX Printing System(tm) - server common files
ii  libcups2:amd64              2.3.3op2-3+deb11u2             amd64        Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:amd64       1.28.7-1+deb11u1               amd64        OpenPrinting CUPS Filters - Shared library
ii  libfontembed1:amd64         1.28.7-1+deb11u1               amd64        OpenPrinting CUPS Filters - Font Embed Shared library

TIA, JT.

[zdohnal]

Hi @jaimet ,

please report this issue to Debian as well, we are at version 2.4.2 upstream, 2.3.3op2 is almost a year old version. It would be great if you tried this with the latest version 2.4.2.

$ sudo lpadmin -p testq -v ipp://inkjet.local:631/ipp/print -E -m everywhere
lpadmin: Unable to create PPD file: No such file or directory

It would be great if you provided CUPS debug logs which happened during the command - please turn on debug logging by cupsctl --debug-logging, try to add your printer via lpadmin and then attach ```/var/log/cups/error_log```` with .txt suffix here.

I don't understand much about cups and IPP, so I'm not sure whether this is a bug, whether it's "by design" (the Canon PIXMA MX925 is not in the list at https://www.pwg.org/printers/ so perhaps this command is supposed to fail), and even if this is a bug, whether or not this is the correct place to report it.

Preemptively I am attaching the outputs from:

ipptool --ippserver printer.attr.txt ipp://inkjet.local:631/ipp/print get-printer-attributes.test printer.attr.txt

Unfortunately the file is incomplete - it shows only one attribute - media-col-database. Please check your get-printer-attributes.test file whether it correctly requests all,media-col-database.

and

driverless ipp://inkjet.local:631/ipp/print > ppdProducedByDriverless.ppd ppdProducedByDriverless.ppd.txt

Ok, so driverless from cups-filters can generate the PPD - and it seems the device supports only Airprint, but it shouldn't be a problem for CUPS PPD generator.

[jaimet]

Hi @jaimet ,

Hi @zdohnal

please report this issue to Debian as well, we are at version 2.4.2 upstream, 2.3.3op2 is almost a year old version. It would be great if you tried this with the latest version 2.4.2.

I haven't reported it to Debian yet (given that Debian stable/Bullseye will probably stay at v2.3.3op2, I'm not sure how much a bug report will help!), but I have "upgraded" the machine from stable (Bullseye) to testing (Bookworm), so here are the (now currently-installed) package versions:

ii  cups                        2.4.2-1                           amd64        Common UNIX Printing System(tm) - PPD/driver support, web interface
ii  cups-client                 2.4.2-1                           amd64        Common UNIX Printing System(tm) - client programs (SysV)
ii  cups-common                 2.4.2-1                           all          Common UNIX Printing System(tm) - common files
ii  cups-core-drivers           2.4.2-1                           amd64        Common UNIX Printing System(tm) - driverless printing
ii  cups-daemon                 2.4.2-1                           amd64        Common UNIX Printing System(tm) - daemon
ii  cups-filters                1.28.15-1                         amd64        OpenPrinting CUPS Filters - Main Package
ii  cups-filters-core-drivers   1.28.15-1                         amd64        OpenPrinting CUPS Filters - Driverless printing
ii  cups-ipp-utils              2.4.2-1                           amd64        Common UNIX Printing System(tm) - IPP developer/admin utilities
ii  cups-ppdc                   2.4.2-1                           amd64        Common UNIX Printing System(tm) - PPD manipulation utilities
ii  cups-server-common          2.4.2-1                           all          Common UNIX Printing System(tm) - server common files
ii  libcups2:amd64              2.4.2-1                           amd64        Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:amd64       1.28.15-1                         amd64        OpenPrinting CUPS Filters - Shared library
ii  libfontembed1:amd64         1.28.15-1                         amd64        OpenPrinting CUPS Filters - Font Embed Shared library
ii  printer-driver-cups-pdf     3.0.1-14                          amd64        printer driver for PDF writing via CUPS

$ sudo lpadmin -p testq -v ipp://inkjet.local:631/ipp/print -E -m everywhere
lpadmin: Unable to create PPD file: No such file or directory

It would be great if you provided CUPS debug logs which happened during the command - please turn on debug logging by cupsctl --debug-logging, try to add your printer via lpadmin and then attach ```/var/log/cups/error_log```` with .txt suffix here.

Ok, using cups v2.4.2, I have redone the commands with debug logging. I have annotated the error_log with the commands that I ran and the output from those commands - I hope it makes sense:

error_log.txt

I don't understand much about cups and IPP, so I'm not sure whether this is a bug, whether it's "by design" (the Canon PIXMA MX925 is not in the list at https://www.pwg.org/printers/ so perhaps this command is supposed to fail), and even if this is a bug, whether or not this is the correct place to report it.
Preemptively I am attaching the outputs from:
ipptool --ippserver printer.attr.txt ipp://inkjet.local:631/ipp/print get-printer-attributes.test printer.attr.txt

Unfortunately the file is incomplete - it shows only one attribute - media-col-database. Please check your get-printer-attributes.test file whether it correctly requests all,media-col-database.

I have redone the same command using v2.4.2:

$ ipptool --ippserver printer.attr.txt ipp://inkjet.local:631/ipp/print get-printer-attributes.test
successful-ok

The "output" (printer.attr.txt) is here - it is identical to the output when I ran the same command using v2.3.3op2 (md5sum: 9e3654...):

printer.attr.txt

(When I ran this ipptool command, nothing was added to the error_log.)

I attach my get-printer-attributes.test (/usr/share/cups/ipptool/get-printer-attributes.test which, according to the package manager, is part of the cups-ipp-utils package) - could you please let me know whether this looks ok or not?

get-printer-attributes.test.txt

I have this funny feeling that the conclusion of this bug report will be that the ipp implementation in the Canon Pixma MX925 is irreparably broken.

Thanks again, J

[zdohnal]

please report this issue to Debian as well, we are at version 2.4.2 upstream, 2.3.3op2 is almost a year old version. It would be great if you tried this with the latest version 2.4.2.

I haven't reported it to Debian yet (given that Debian stable/Bullseye will probably stay at v2.3.3op2, I'm not sure how much a bug report will help!),

If there is a fix regarding the issue here already or there can be a fix, Debian maintainers can backport the fix to the stable, but as you've guessed, there probably won't be any :( .

but I have "upgraded" the machine from stable (Bullseye) to testing (Bookworm), so here are the (now currently-installed) package versions:

Thanks, that helps a lot!

Ok, using cups v2.4.2, I have redone the commands with debug logging. I have annotated the error_log with the commands that I ran and the output from those commands - I hope it makes sense:

Thank you! I see the following error:

E [03/Jun/2022:13:08:02 +0100] testq: PPD creation failed: Printer does not support required IPP attributes or document formats.

Based on the output you've shared from ipptool (which is really the same as you said) my guess is your printer is not capable processing list of requested attributes, but it only takes the last one from the list and sends response for it...

I attach my get-printer-attributes.test (/usr/share/cups/ipptool/get-printer-attributes.test which, according to the package manager, is part of the cups-ipp-utils package) - could you please let me know whether this looks ok or not?

Looks fine - the line with requested attributes is correct and the same as mine:

ATTR keyword requested-attributes all,media-col-database

I have this funny feeling that the conclusion of this bug report will be that the ipp implementation in the Canon Pixma MX925 is irreparably broken.

Broken it is, but I wouldn't say irreparably - please check whether there is a new firmware update for the printer and try the installation via everywhere again.

Other thing we can check is a traffic capture - check whether we really send IPP request with all, media-col-database and the printer reports only media-col-database.

It would be great if you captured and attached the file with network traffic when you do the request. You can do it via:

sudo tcpdump -s0 -w <name>.pcap -i <your_network_interface>

[jaimet]

please check whether there is a new firmware update for the printer and try the installation via everywhere again.

Unfortunately there is no later version of firmware available - I'm already running the latest (v3.041).

Other thing we can check is a traffic capture - check whether we really send IPP request with all, media-col-database and the printer reports only media-col-database.

It would be great if you captured and attached the file with network traffic when you do the request. You can do it via:

sudo tcpdump -s0 -w <name>.pcap -i <your_network_interface>

Here is the result of running sudo tcpdump -n -w tcpdump.pcap port ipp (and running sudo lpadmin -p testq -v ipp://inkjet.local:631/ipp/print -E -m everywhere in another terminal), zipped so that github will accept it:

tcpdump.pcap.zip

(If tcpdump.pcap is not in the correct format, then please let me know.)

A couple of different questions:

1. If sudo lpadmin -p testq -v ipp://inkjet.local:631/ipp/print -E -m everywhere is unable to create a .ppd file in /etc/cups/ppd, should it print an error message and/or have a return code different to 0?

2. If sudo lpadmin ... cannot create a .ppd file, how come driverless can? Is it just that driverless is more "forgiving" (than sudo lpadmin) of the MX925's broken ipp implementation?

[zdohnal]

(If tcpdump.pcap is not in the correct format, then please let me know.)

That's alright - so from the capture I see we really send the correct request, but the device responds only by media-col-database.

A couple of different questions:

1. If `sudo lpadmin -p testq -v ipp://inkjet.local:631/ipp/print -E -m everywhere` is unable to create a `.ppd` file in `/etc/cups/ppd`, should it print an error message and/or have a return code different to `0`?

Hmm... do you get this specific error with 2.4.2 as well? Because IIUC since 2.4.1 there is a bug that the command fails silently (#347) because we generate the PPD in separate thread and don't wait for result AFAIK. But sending 0 for error is a bug as well.

2. If `sudo lpadmin ...` **_cannot_** create a `.ppd` file, how come `driverless` **_can_**? Is it just that `driverless` is more "forgiving" (than `sudo lpadmin`) of the MX925's broken ipp implementation?

I've checked driverless implementation - its author implemented fallbacks for this problem there, but really it should be fixed in firmware, because it's a problem that Airprint certified printer is not able to respond to a correct IPP request... - please report it on Canon support, probably https://global.canon/en/support/ or your local Canon support...

We will discuss whether we will add this compatibility hack into CUPS (probably based on whether we will have some place where manufactures will sometime check if there is a bug in their firmware...), but I wouldn't rely on it for now...