CUPS – Known Issues

cups-browsed sometimes loses connection to print server (usually with old ones, like cups-1.4.2) when laptop changes network connection (change of WiFi network or after hibernate/suspend). You can make printing working again with cancelling your jobs and restarting cups-browsed by

Creating local printer queues takes long time for some printers with larger PPD file, so timeout of http connection will time out and it creates infinite loop of creating local printer queues. To solve this issue, please add

into /etc/cups/cups-browsed.conf, where N is number of seconds after which connection is timed out. Then restart cups-browsed service. This option is currently in Fedora 27 and above.

This issue is connected to remote cups queues, which are advertised by older CUPS version (usually below cups-1.5, e.g. RHEL 6). Cups-browsed creates local print queues named by printer’s DNS-SD ID by default and naming by remote cups queue is enabled again by adding:

into /etc/cups/cups-browsed.conf and restart cups-browsed service.

When your printer needs a lot of time to do printing (from your POV) or doesn’t print at all (some Xerox printers have such problems with gs renderer, so they are working again only with pdftops renderer), you can try to change the default postscript renderer. The default renderer in Fedora for most printers is gs filter from Ghostscript, but we have pdftops filter from Poppler for Brother, Minolta and Konica Minolta printers - this setup is called hybrid.

Other available renderer setups are gs (from Ghostscript), pdftops and pdftocairo (from Poppler), mupdf (from mupdf) and acroread (from adobe reader, not in Fedora official repositories), then you can set different default renderer for your print queue like this:

BEWARE: Most 'slow' printing issues are caused by PDF creating applications, which generates bad PDF file - and that bad generated PDF file is mostly the core of problem. To sum it up, slow printing issue can rise again with different PDF file, then it is on user’s decision: if he wants to print fast and probably sometimes change the default renderer, or slow printing is not such critical issue.

This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources - mDNS messages from Avahi and CUPS - this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn’t exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn’t exist.

The feature which GTK is trying to do here is called CUPS temporary queues - GTK developers is currently working on a immediate fix in this bugzilla. The future plan is to use cpdb-backend-cups backend in GTK, but right now we are focusing on the intermediate fix.

CUPS sometimes has problems with some kinds of FQDN - that means when you use FQDN in BrowsePoll directive in /etc/cups/cups-browsed.conf, CUPS doesn’t recognize it as valid hostname - it is solved by adding:

into /etc/cups/client.conf and restarting cups service.

The similar situation can happen with sane-airscan supported scanners. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device’s firmware, which can be verify by checking the output of the following command:

The commands does the same IPP request which is done when a temporary queue appears in the print dialog or when you install the queue permanently. The printer options are set from the IPP response for this request, so if the option is missing in the response, CUPS cannot generate such a printer option. The solution is to try to update the device firmware, report the issue to the device manufacturer and at bugzilla with logs.

Fedora 33 came up with a raised bar regarding crypto-policies, so SSL and older TLS protocols are disabled on system level. The change breaks printing via IPPS to devices which don’t support newer protocols. You can set back legacy crypto support in crypto-policies via:

The policy change transitionally has an impact on devices found by cups-browsed, because the daemon prefers IPPS uris if they are reported as available by printer/server.

This common error is mostly caused by external causes (server outage, network outage), when wget tries to download plugin, but it returns only error message. It is connected with message:

where N is return value of wget (man wget), which is used for downloading proprietary plugin. Solutions for this issue may vary - you can wait until servers go up again or try to install plugin, which you download manually from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (select "Select and install an existing local copy of the plug-in file" during hp-setup or hp-plugin).

This error can occur when hplip is installed from HP website, or its dependencies are mixed python2 and python3 packages or installed by pip. This is solved by removing all hplip packages (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) and installing them again all from repositories.

GUI tools and GUI parts of HP commands are moved to hplip-gui subpackage, because the main package can work without GUI, so the main package is smaller. The outcome of this decision is HP commands need to be run with -i option for interactive mode, or hplip-gui subpackage needs to be installed.

Tools, which need to be run with -i option for CLI or need to have hplip-gui installed for GUI:

Tools, which are in hplip-gui:

Some HP printers don’t work well with URIs provided by CUPS (dnssd, usb, ipp) or they need proprietary plugin from HP, which cannot be in Fedora because of licensing issues. For such printers please try to run:

for interactive mode, or:

for graphic mode. This command installs HP printers and HP scanners. If you have issue about HP printer/HP scanner, which isn’t discovered, doesn’t print or doesn’t print well, please try to install it by hp-setup, if it helps. If it doesn’t help, please file a bugzilla, attach output of hp-setup and mention that you tried hp-setup.

Devices which need plugin can stop to work after update to newer HPLIP version - it is due the check for plugin version in the code. The check is necessary to prevent inconsitencies when new features in open sourced HPLIP need new proprietary libraries from plugin. To make your printer work again, just download and install plugin again with:

Devices which require a HP close source binary plugin need to have plugin installed every time you start/restart your PC by default. HP closed source script installs the plugins into a readonly directories, so the plugins are removed once you start/restart Fedora. The workaround is to try if your device supports driverless printing and scanning, try hplip-plugin package from RPMFusion or keep installing the plugin everytime you want to print.

ipp-usb daemon keeps the USB port of IPP-over-USB device opened for any possible IPP communication in the future, which blocks the port for other drivers (f.e. HPLIP, gutenprint, sane-backends…​).

For printers the solution is to uninstall the queue with the driver by:

and start using the one from ipp-usb (as a CUPS temporary queue or install a permanent one - the default device uri is ipp://localhost:60000/ipp/print).

In case of scanners sane-airscan automatically picks up the virtual device from ipp-usb if the device is capable of using WSD or eSCL protocols. However, if the scanner had been supported by classic scanner driver such as hplip or sane-backends and is now claimed by ipp-usb because it supports IPP-over-USB driverless standard, the old scanner is still shown, but it won’t work for scanning due USB conflict. It happens because classic backends just list any device which they can find on USB interfaces and matches the description the backend supports, but backends don’t check whether they actually can communicate with the device until they try to open the USB port for scanning process itself. This becomes a problem for scanning applications, which automatically choose the previous scanner as a default choice for scanning (such as Simple Scan) - users have to pick a driverless scanner from the list of available scanners before they scan.

The scanner device discovered by classic SANE backends can be disabled from showing it among available scanners by commenting out its entry in backend’s configuration file located in /etc/sane.d or the whole backend name in /etc/sane.d/dll.conf//etc/sane.d/dll.d, f.e. Canon MF440 Series is reported by pixma and airscan backends, but only airscan works because it is a backend based on network protocol and USB interface is claimed by ipp-usb, so we will disable the pixma backend by commenting its line in /etc/sane.d/dll.conf:

If ipp-usb created device doesn’t match your use case (the options you use are missing, the device doesn’t work even if it is IPP-over-USB supported), please report the issue together with logs from /var/log/ipp-usb/ directory at bugzilla. ipp-usb itself supports quirks, which allows you to set the daemon to ignore your device and you can switch back to a classic driver. The steps are following:

The similar situation can happen with everywhere or driverless printer models. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device’s firmware, which can be verify in sane-airscan debug logs and network traffic. The solution is to try to update the device firmware, report the issue to the device manufacturer and at bugzilla with logs.