lpadmin: Unable to create PPD file: No such file or directory - for an Airprint printer

[Motherboard]

Trying to add a permanent queue for iP7250 (which should work with Airprint)

I am able to print using lp -d Canon_iP7200_series <file name>, - and a temporary queue is created for a minute, but lpadmin -p ip7200 -v ipp://Canon%20iP7200%20series._ipp._tcp.local/ -E -m everywhere (the URI I get from lpstat -l -e) fails with lpadmin: Unable to create PPD file: No such file or directory.

The same error message occurs when trying the URI I get from driverless (ipp://411824000000.local:631/ipp/print).

Attached is the output from ipptool -tv ipp://411824000000.local:631/ipp/print get-printer-attributes.test
cups-queue-driverless-ip7250.txt

Why can't I add a permanent queue, but can print and have a temporary one?

[michaelrsweet]

@Motherboard What version of CUPS are you using? What operating system?

[Motherboard]

CUPS version 2.2.7, OS mint 19.1.

[Motherboard]

Do you think this is related?

Here's the output for the modified test from that issue:
ipp_attr2.txt

[michaelrsweet]

@Motherboard Possibly, there have been many changes to the IPP Everywhere support since CUPS 2.2.7... Can you try using the current stable release of CUPS (2.2.10)?

[Motherboard]

Yes, it happens with CUPS 2.2.10 on Ubuntu 19.04 daily.

[michaelrsweet]

OK, thank you.

This might be related to Issue #5484, particularly since this vendor's printers don't seem to conform to the rules for requested-attributes (no support for attribute group names, just "all").

[tillkamppeter]

There are several users complaining about driverless printing not working with Canonm printers. See also the (here already mentioned earlier) cups-filters issue #22. It seems that the Canon cannot cope with the added "media-col-database" attribute. Then the response to the get-printer-attribute requests comes out incomplete. Either there is a firmware bug in the Canon printers or the response gets perhaps somehow too long for the client-side implementation of IPP (libcups in case of both CUPS and cups-filters). So testing with the alternative implementation ippsample is needed.

[michaelrsweet]

@tillkamppeter The client-side implementation has no limits on the number of attributes, and any size limits are in the protocol and not in the software. It is far more likely there is a firmware bug, given that their printers don't seem to properly support attribute groups.

I'll see if I can get access to a recent Canon AirPrint printer and do some testing...

[michaelrsweet]

OK, I have a printer on the way - won't have it until next Wednesday but I think the issue is the same as #5484. Will confirm next week...

[Motherboard]

By the way, CUPS 2.2.10 behaves even worse for me than 2.2.7 - I can no longer see any output for driverless, lpstat -e only occasionally sees the printer, and lp -d says lp: No such file or directory when trying to print a file using it (which worked fine with the previous version).

localhost:631 doesn't see any printers as well until I manually add the printer (using the URI I got from driverless using the previous system) and add it with gutenprint driver.

[michaelrsweet]

I don't think there were any DNS-SD changes between 2.2.7 and 2.2.10, just IPP Everywhere changes, but as soon as I get my printer I'll start testing (on multiple platforms) to make sure we have this nailed down.

[tillkamppeter]

In the cups-filters issue #22 a user tried the ipptool of PWG's ippsample and runs into the same problem. So it seems that the problem occurs with both libcups and ippsample.