mDNS hostname in device URI is not resolved during permanent IPP Everywhere queue installation

[Zeioth]

To generate the ppd of my printer, I went to http://localhost:631/admin added my printer, and choose the model. Works. all good.

This has generated '/etc/cups/ppd/EPSON_ET-1810_Series.ppd' so I tought "Cool, I'm gonna create the printer through a command, so I don't have to manually configure it every time I reinstall my system".

So I ran

lpadmin -p epson-et1810 -E -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m /etc/cups/ppd/EPSON_ET-1810_Series.ppd

And it doesn't work. Doesn't add the printer. The output is:

lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS.
lpadmin: cups-driverd failed to get PPD file - see error_log for details.
lpadmin: The printer or class does not exist.

Where is any way to bypass this error?
Thank you.

[zdohnal]

Hi @Zeioth ,

thank you for the question and here are answers and tips:

1. if you install print queue via lpadmin with a file, -P is the option you seek instead of -m,
2. since the device uri shows ipps and mDNS hostname, my take is your printer can do AirPrint, so it is supported in CUPS by IPP Everywhere - so you can install a permanent queue for your printer by -m everywhere
3. if your machine (laptop, desktop PC) lives in trusted network, you don't need to install the queue at all - applications which support CUPS temporary queues are able to pick up the queue when you are going to print and the queue disappears after successful printing. If an application doesn't support this, it would be great if you reported the fact to them and ask them to support CUPS temporary queues.

I hope it helps and have a nice day :)

[Zeioth]

Good morning.

1. According to man, the argument -P is deprecated, -p seems to be the right one.
2. If I do that, the printer only prints garbage, instead of the content of the file to print. Meaning, the drivers would not be correct.
3. Answering you, I normally print all files in a certain directory with this alias:

print_pdfs_in_current_dir() {
  # Prints all the files in the specified document 
  PRINT_FORMAT="A4"
  PRINT_QUALITY="4"

  TOTAL_FILES=$(ls -l $STAGED_DIR | grep pdf | wc -l)
  current_file=0

  echo "FILES ADDED TO PRINTING QUEUE..."
  echo "run print-list to see the current status."
  echo "================================"
  for filename in $PWD/*.pdf; do
    [ -e "$filename" ] || continue
    echo "Printing file $current_file/$TOTAL_FILES... → $filename"
    lp -t "$filename" -n 1 -o print-quality="$PRINT_QUALITY" -o media="$PRINT_FORMAT" "$filename"
  done
  echo "================================"
  echo "PRINTING JOBS STARTING"
}
alias print-start="print_pdfs_in_current_dir"
alias print-cancel="cancel -a"
alias print-list="lpq"

I don't see a good reason to close the issue. If you could re-open it that would be great.

[zdohnal]

Good morning.

1. According to man, the argument -P is deprecated, -p seems to be the right one.

You're mixing two things together - -p sets the name for your print queue, -P sets a file you pass as an argument as print queue driver, f.e.:

$ lpadmin -p test -v socket://192.168.5.5 -P /path/to/the/file -E

You're right about -P deprecation, but every argument of -m except for everywhere is deprecated as well. So if you want to use a file for print queue installation, you can only use the deprecated options.

Or install the queue as IPP Everywhere, which recommend in the rest of comment.

2. If I do that, the printer only prints garbage, instead of the content of the file to print. Meaning, the drivers would not be correct.

Once you use the correct model (-m everywhere) or (if you insist) a file with correct option, the permanent queue should work. But you don't need to install the queue at all, because it looks like it is supported by IPP Everywhere -> you can use temp queue.

3. Answering you, I normally print all files in a certain directory with this alias:

print_pdfs_in_current_dir() {
  # Prints all the files in the specified document 
  PRINT_FORMAT="A4"
  PRINT_QUALITY="4"

  TOTAL_FILES=$(ls -l $STAGED_DIR | grep pdf | wc -l)
  current_file=0

  echo "FILES ADDED TO PRINTING QUEUE..."
  echo "run print-list to see the current status."
  echo "================================"
  for filename in $PWD/*.pdf; do
    [ -e "$filename" ] || continue
    echo "Printing file $current_file/$TOTAL_FILES... → $filename"
    lp -t "$filename" -n 1 -o print-quality="$PRINT_QUALITY" -o media="$PRINT_FORMAT" "$filename"
  done
  echo "================================"
  echo "PRINTING JOBS STARTING"
}
alias print-start="print_pdfs_in_current_dir"
alias print-cancel="cancel -a"
alias print-list="lpq"

The temp queue works with your setup as well - just check whether CUPS actually sees it - which means the printer isn't on the list of accepting printers (output of lpstat -a), but it is on the list of existing printers (lpstat -e).

[michaelrsweet]

@Zeioth The PPD file in /etc/cups/ppd isn't where you'll find it on a fresh system, it is the currently configured PPD for that queue. Ordinarily PPD files are copied either from a driver information file (/usr/share/cups/drv), a PPD file (/usr/share/cups/ppd), a driver interface program (used by Gutenprint in particular - /usr/lib/cups/driver), or from a PPD generated by CUPS for an IPP printer.

For non-IPP printers, the lpinfo -m command can be used to find the driver name you can pass to lpadmin with the -m option. For IPP printers you just pass -m everywhere to lpadmin to generate a PPD for the printer.

The -P and -i options specify a path to a PPD file. You only use these options for a PPD file in a non-standard location.

But as @zdohnal mentioned, for any printer sold in the last 10 years or so you probably want to use the "everywhere" model or just use (automatically-created) temporary queues.

[Zeioth]

Hello thank you for your answers:

-m everywhere is incompatible with my new adquired printer (see photo)

About -m -i and -P I get a deprecation error (see first post) that prevents lpadmin to add the printer.

So effectively I have no way to add my printer using lpadmin.

[michaelrsweet]

@Zeioth The deprecation warning does not prevent the queue from being added. Not having the PPD file in the location you specify will.

(deprecation == warning, obsolete == error)

[michaelrsweet]

@Zeioth And looking at the EPSON ET-1810, I'm astonished that it doesn't support AirPrint but you need to make a copy of the PPD file (or use the lpinfo -m command to find the model name) to run a fresh lpadmin command - as I said before the PPD file in /etc/cups/ppd is only present for an existing print queue, it is not where the files are copied from!

[Zeioth]

Ok so, I went to epson's website and I found the PPD for my printer. Unexpectedly, epsom seem to have pretty good linux support. There's also seem to be an arch package with the same name.

lpadmin -p epson-et1810 -E -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -i /usr/share/ppd/epson-inkjet-printer-escpr/Epson-ET-1810_Series-epson-escpr-en.ppd # Add the printer to lp
lpadmin -d epson-et1810 # set as default printer

This time the command added the printer correctly and prints correctly too.
Thank you, you helped me a lot.

[Zeioth]

Please don't eliminate PPD support or I won't be able to install my printer, and I bet a lot more of people. Printer makers are still using PPDs.

Next time I'll look for an IPP everywhere printer, at it seems it's gonna be the new standard, and being driverless is a great adventage that makes configuration easier.

[michaelrsweet]

@Zeioth It is happening, but we've been working with everyone (for about 5 years now) to develop "Printer Applications" which do the same thing as printer drivers in an IPP-compatible way. Most non-AirPrint/Mopria/IPP Everywhere printers are supported by printer applications already, and it will be a couple more years before we ship the first version of CUPS without PPD support.

[Zeioth]

@michaelrsweet I just noticed the printer also prints correctly through the protocol dnssd (added from cups web server).

What would be the format to add a dnssd printer by using lpadmin?

[michaelrsweet]

@Zeioth The "dnssd" backend just resolves the correct protocol from those the printer reports, so if you do lpstat -v on a configured printer you will see what the device URI is to pass with the -v option to lpadmin.

Similarly, you can use lpinfo -v to list the available printers and their device URIs.

[Zeioth]

Oh that's a shame

lpadmin -p epson-et1810 -E -v dnssd://EPSON%20ET-1810%20Series._ipp._tcp.local -m everywhere

Adds the printer correctly but still prints garbage when used with -m everywhere. It seems the printer it just not compatible with the IPP everywhere, actually.

[zdohnal]

@Zeioth

I'm sorry, I've misunderstood you - I thought you didn't use -m everywhere or '-P 'file'' and that's when you got the error. If I understood you have problems with -m everywhere or otherwise passed a correct options, I wouldn't close the issue.

@Zeioth Would you mind providing the information from the following steps:

==========================================================

1. It would be great if you could attach the file output.txt of the following command here as a file (it needs .txt suffix):

$ ipptool -tv ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ get-printer-attributes.test > output.txt

the command sends a query to the printer to find out what are the features/settings available on the printer - it can give us idea why everywhere model doesn't work there.

===========================================================

2. The information that your printer works with dnssd when you add it via Web interface and ipps uri you've been using - IMO it is not an uri which a human can set up by himself - you've probably copied it from somewhere - probably from CUPS web ui or lpinfo -v. And CUPS IPP backend doesn't discover devices automatically like that, so my guess is it is an uri from driverless backend.

Would you mind installing your queue by the following command and tell us whether the queue works:

$ lpadmin -p <name> -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m driverless:ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -E

?

=============================================================

@michaelrsweet if it is not a bug in PPD generator in CUPS, it can be a device which supports driverless standard we still don't support in CUPS - f.e. apple/cups#6022 - it seems like some devices support only PCLm, which CUPS doesn't support yet.

[Zeioth]

Hello apologies for the delay:

1. The output from ipptool don't show 'everywhere', but it shows 'airprint'.
   output.txt

2. The second command, prints correctly without needing drivers!! Neat!

[zdohnal]

From the get-printer-attributes.test output:

document-format-supported (1setOf mimeMediaType) = application/octet-stream,image/pwg-raster,application/vnd.epson.escpr

The device supports image/pwg-raster format, so -m everywhere should work - so it is a bug in our PPD generator.

@Zeioth I would like to ask to attach several files (if they don't have .txt suffix, please copy them somewhere, add the suffix and attach them here):

1. get the printer attributes in attributes format which can be passed to printer application - this will help to simulate your printer in my local environment - the resulting file is called printer.attr

$ ipptool --ippserver printer.attr ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ get-printer-attributes.test

2. get logs when you print to 'everywhere' queue and when you print to 'driverless' queue - to see differences between successful and bad printing.

• enable cups logs via cupsctl --debug-logging,
• locate the logs (Fedora, RHEL 8+ and CentOS/CentOS Stream 8+ have logs in journal - accessible with journalctl -u cups, others in /var/log/cups/error_log),
• install the broken queue - lpadmin -p epson-et1810 -E -v dnssd://EPSON%20ET-1810%20Series._ipp._tcp.local -m everywhere
• print to working queue and then to broken queue
• attach error_log here as .txt, or redirect cups related logs from journal journalctl -u cups > log.txt

3. attach generated PPDs for both queues, if there are any (cups-2.4.0 and newer doesn't generate a file for '-m everywhere', but driverless should still generate a file in /etc/cups/ppd) - again I can check for differences between those two.

Thank you in advance!

[michaelrsweet]

@Zeioth In addition to what @zdohnal requested, please also attach the PPD file in /etc/cups/ppd for the printer so that we can see what is in there. This printer supports Wi-Fi Direct Print Services but not AirPrint or Mopria for some reason (maybe it wasn't able to do the media sensing that AirPrint requires? no media-ready or media-col-ready in there) but has everything needed for IPP Everywhere.

[Zeioth]

Ok this should be all.
compresed_files.zip

I only want to point out 2 things:

• In the logs, I first ran a successful print, and after, the borked one.

• There is no borked PPD because /etc/cups/ppd don't even create one if I set "-m everyone" in lpadmin. I only attached the working one generated from:

  lpadmin -p <name> -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m driverless:ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -E

Btw this command is what I understand by 'working' on this tests.

[Zeioth]

Feel free to ask me anything, I'll be around.

[michaelrsweet]

@Zeioth The "-m everywhere" should have produced a PPD file, otherwise the command should have produced an error.

What version of CUPS are you using?

[zdohnal]

@michaelrsweet from the driverless PPD Zeioth attached I see there is CUPS 2.4.x in use, so IIUC we don't generate PPD there...

*cupsVersion: 2.4

[michaelrsweet]

@zdohnal Even temporary queues have PPD files, they just disappear when the temp queues go away. It won't be until CUPS 3.0 that we do away with PPDs...

[zdohnal]

Hmm... now I've run CUPS 2.4.1 in my VM and even a permanent IPP Everywhere queue leaves a PPD... I could've swear I tested it upstream before 2.4.0 release and there was no PPD...

@Zeioth

* **There is no borked PPD** because /etc/cups/ppd don't even create one if I set "-m everyone" in lpadmin. 

Aha - that may be a reason why no PPD was created - the string should be -m everywhere. Would it be possible if you recreated the queue and capture the logs when printing to it? You can only pass one page to the printer, you don't need to pass whole doc there (I saw in the log there were several pages in the job) - the issue should be triggered even with the one page. On the top of that, you can reuse the paper from previous jobs.

Ideally it would be interesting to try device uri without mDNS hostname - then we can cross out any mDNS/Avahi related issues - uri would be like:

ipp://<printer's hostname/IP>:631/ipp/print

[zdohnal]

@Zeioth Can you check if the referenced commit helps you when you install the permanent IPP Everywhere queue with mDNS hostname-based URIs?

I tested the fix in Fedora with temporary queue and permanent queues with IPP Everywhere model and two different uris - one with IP, other with mDNS hostname - all three worked.

[VorpalBlade]

@zdohnal I checked that commit, and it did not change the behaviour at all for issue #343 which I believe was marked as a duplicate of this bug.

I rebuilt the cups and libcups packages with the commit applied. I installed these versions, then did systemctl restart cups.

Here is the new debug log: debug_log.txt The printer still shows up as a raw printer in the web UI.

EDIT: The printer changed type by itself after waiting a few minutes. I guess it was just slow to figure things out? Is that expected behaviour?

[Zeioth]

I tested this with this two commands, and neither of them creates the ppd yet:

lpadmin -p epson-et1810 -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m everywhere -E
lpadmin -d epson-et1810 # set as default printer
echo "Printers installed:"
lpstat -p | awk '{print $2}'
# No ppd at this point
lpadmin -x epson-et1810

lpadmin -p epson-et1810 -v ipp://192.168.1.101/zeioth-pc:631/ipp/print -m everywhere -E
lpadmin -d epson-et1810 # set as default printer
echo "Printers installed:"
lpstat -p | awk '{print $2}'
# No ppd at this point either

[zdohnal]

@VorpalBlade cupsd has 'DirtyCleanInterval' directive which sets a time after which cupsd updates printers.conf file - the behavior you've seen can be explained by it - the more important thing for now is whether the print queue works - meaning it prints correctly. Have you verified that?

@Zeioth the cups-git you've used is for Apple CUPS, not ours + if you see <IP/hostname>, it was supposed to mean 'substitute by IP or hostname', not by both.

[VorpalBlade]

@zdohnal I did not check that before, I assumed that the web UI would be based on the current state of the daemon, not the config file.

I did check now however, and no, I was not able to print immediately after, it took about half a minute to update in this case and allow printing (printer added via lpadmin, test print via lp). This seems problematic and potentially confusing to users.

In addition when adding a printer via the web UI and selecting the discovered IPPS-via-mdns printer: The last step of the "wizard" is to set default printer options. As the printer is still a raw printer at this stage, the only options available are banner pages and policy. This is also a confusing user experience, having to wait a bit and then go back into the printer settings to set page size etc.

EDIT: This is also a problem when adding via IP in the web UI: The option page is not correct until after the printer has been added, and it is a raw printer to begin with. Is this a separate bug?

[michaelrsweet]

@zdohnal In this case it isn't the DirtyCleanInterval per-se, but the processing that cupsd needs to do in a background thread to generate the PPD.

@VorpalBlade Unfortunately, the current implementation of cupsd is essentially single-threaded. The whole "resolve and generate the PPD in the background" trick can't be done in the (main) IPP request processing thread, so there is no way with the current implementation to delay a response to the CUPS-Add-Modify-Printer request. But we might be able to do something in admin.cgi to special-case the IPP Everywhere driver and wait until a PPD is found. If you can file a separate bug on that specifically I'll see what can be done...

[VorpalBlade]

@michaelrsweet Sure, I can do that later today when I have more time. What about the case of the user adding the printer through the Gnome printer settings though? Or the KDE one (I assume it has it's own separate one).

[michaelrsweet]

@VorpalBlade Note it in the bug and we'll figure something out. It is a "short term" problem as future CUPS won't have this issue (no more PPD files... :), but I'd like to do something about it because it is definitely confusing.

[zdohnal]

@michaelrsweet thank you, Mike!

[Zeioth]

Thank you for pointing that out @zdohnal you right, the cups AUR repos are outdated. I hope I can find time this week to fix that aur repo and make it point here.

I'm not gonna try compiling directly from git because I'd rather to avoid garbage in my system. I'll re-test the issue once it reaches arch offiical repos.

But I tried this two in the current version and still don't create the PPD:

lpadmin -p epson-et1810 -v ipp://192.168.1.101:631/ipp/print -m everywhere -E
lpadmin -p epson-et1810 -v ipp://zeioth-pc:631/ipp/print -m everywhere -E

[VorpalBlade]

Thank you for pointing that out @zdohnal you right, the cups AUR repos are outdated. I hope I can find time this week to fix that aur repo and make it point here.

I'm not gonna try compiling directly from git because I'd rather to avoid garbage in my system. I'll re-test the issue once it reaches arch offiical repos.

I just took the official repo CUPS one, modified the PKGBUILD to include the commit as a patch and rebuilt it. I can upload my PKGBUILD & associated files as a tarball somewhere if you want.

[Zeioth]

@VorpalBlade Yes please, I have enough time to test if you could.

[VorpalBlade]

@VorpalBlade Yes please, I have enough time to test if you could.

cups.tar.gz

[Zeioth]

Ok I tried the next commands generating the arch package from your PGKbuild and the PPD still doesn't get generated by any of the commands I tried:

lpadmin -p epson-et1810 -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m everywhere -E
lpadmin -p epson-et1810 -v ipp://192.168.1.101:631/ipp/print -m everywhere -E

Also It's very easy to notice when the command is not creating the PPD in /etc/cups... because the command runs instantly, while when the PPD is created correctly there is an small delay before the command finishes (like with the one it works for me)

lpadmin -p epson-et1810 -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m driverless:ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -E

[zdohnal]

@Zeioth If you still check the existence of PPD by your constructed command, which checks the PPD right after lpadmin exits, you probably hits the delay in PPD generation as described in #347 . The PPD gets generated after some delay depending on your network setup (f.e. I get my IPP Everywhere generated in matter of seconds - 2-3s, so IMO it is influenced by the network setup?). In the end, the PPD should get generated in some time - please check /etc/cups/ppd folder after several seconds.

[Zeioth]

No, it's not created no matter what. (Ryzen 5950 + 1Gb internet connection. /etc/cups/ppd remains empty after 5 minutes).

[zdohnal]

@Zeioth can you attach a txt file with CUPS debug logs from the time you add the print queue:

lpadmin -p epson-et1810 -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m everywhere -E

?

[debiantriage]

Debian has cups 2.4.1op1-1. I am using it.

TEST-1:

root@test:~# lpstat -l -e
ENVY4500 network none ipp://ENVY4500._ipp._tcp.local/

root@test:~# lpadmin -p testq -v ipp://ENVY4500._ipp._tcp.local/ -E -m everywhere

root@test:~# lpoptions -p testq -l lpoptions:
Unable to get PPD file for testq: Not Found

root@test:~# ls -l /etc/cups/ppd/
total 0

printers.conf is written to and lpstat -ashows testq.

TEST-2:

root@test:~# lpadmin -x testq

root@test:~# ippfind
ipp://envy4500.local:631/ipp/print

root@test:~# lpadmin -p testq -v ipp://envy4500.local:631/ipp/print -E -m everywhere

root@test:~# ls -l /etc/cups/ppd/
-rw-r----- 1 root lp 14770 Mar 7 15:18 testq.ppd

log-1 has

Unable to connect to ENVY4500._ipp._tcp.local:631: Name or service not known

log-1.txt
log-2.txt

[debiantriage]

lpadmin -p epson-et1810 -v ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -m driverless:ipps://EPSON%20ET-1810%20Series._ipps._tcp.local/ -E

@Zeioth What output does that command produce?

[zdohnal]

@debiantriage Hi Brian,

have you applied the latest patch from git master regarding the issue?

55359b9
777c1ec

[Zeioth]

@debiantriage That's the only command that works for me so far. It creates the PPD correctly under /etc/cups/ppd

[debiantriage]

@zdohnal Hello Zdenek,

I forgot about about those patches. Reminding me was good.
Patching and building CUPS is not in my skill set, so I will wait on an updated Debian package.

Apologies for the noise and thank you for your work.

[zdohnal]

@debiantriage np, please let me know if it helps - there is a known connected issue #347 about a possible delay between the time when lpadmin/CUPS Web UI finishes adding the queue, but the background thread generating the PPD hasn't finished yet - which causes CUPS Web UI/lpoptions showing the queue as a raw for some time.

[debiantriage]

@zdohnal @michaelrsweet @Zeioth

Debian now has a cups 2.4.2-1 package. The cups changelog has
Issues #340, #343 as fixed:

• mDNS hostname in device uri is not resolved when installaling a permanent IPP Everywhere queue

Repeating TEST 1:

root@test:~# lpstat -l -e
ENVY4500 network none ipp://ENVY4500._ipp._tcp.local/

lpadmin -p testq -v ipp://ENVY4500._ipp._tcp.local/ -E -m everywhere

This command completes and immediately produces a PPD.

root@test:~# ls -l /etc/cups/ppd/
-rw-r----- 1 root lp 14770 Jul 11 14:41 testq.ppd

That's an improvement on the previous outcome. The issue seems to me to be fixed.