quick-docs/modules/ROOT/pages/_partials/con_cups-known-issues.adoc

[id='con_cups-known-issues']
= Known issues

Here are several known issues, which arise with certain circumstances, and there isn't general solution or upstream didn't want to add the solution to its project:

== cups-browsed

=== Cannot print due 'No destination hostname provided by cups-browsed, is it running?'


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

----
$ cancel -a
$ sudo systemctl restart cups-browsed
----

=== cups-browsed consumes large amount of CPU

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

----
HttpLocalTimeout N
HttpRemoteTimeout N
----

into [filename]`/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.

=== [SINCE FEDORA 27] cups-browsed creates different printer queue names than before

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:

----
LocalQueueNamingRemoteCUPS RemoteName
----

into [filename]`/etc/cups/cups-browsed.conf` and restart cups-browsed service.

== cups-filters

=== Printing takes a long time or doesn't print at all

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:

----
# lpadmin -p <printer-name> -o pdftops-renderer-default=gs/pdftops/pdftocairo/mudpf/acroread/hybrid
----

*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.

== CUPS

=== [Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a 'dummy'/duplicate print queue, which doesn't work

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 https://bugzilla.redhat.com/show_bug.cgi?id=1784449[bugzilla]. The future plan is to use https://github.com/OpenPrinting/cpdb-backend-cups[cpdb-backend-cups] backend in GTK, but right now we are focusing on the intermediate fix.

===  CUPS doesn't take nicely some kinds of FQDN

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

----
ServerAlias your.own.fully.qualified.hostname.com
----

into [filename]`/etc/cups/client.conf` and restarting cups service.

=== There are less options available if the device is used as driverless than with a classic driver

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:

----
$ ipptool -tv <ipp_device_uri> get-printer-attributes.test
----

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 https://bugzilla.redhat.com[bugzilla] with logs.

=== [F33+] Printing via IPPS doesn't work

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:

----
$ sudo update-crypto-policies --set DEFAULT:FEDORA32
----

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.

== HPLIP

First I would like to mention that we are not responsible for support HPLIP, which is downloaded and installed from HP website. Please install hplip rpms from official Fedora repositories at most cases.

=== Hp-plugin: file does not match its checksum. File may have been corrupted or altered

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:

----
Plugin download failed with error code = N
----

where `N` is return value of [command]`wget` ([command]`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 [command]`hp-setup` or [command]`hp-plugin`).

=== Unable to load cupsext

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.

=== Missing hplip-gui

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:

----
hp-align
hp-clean
hp-colorcal
hp-diagnose_queues
hp-fab
hp-firmware
hp-info
hp-plugin
hp-sendfax
hp-setup
hp-testpage
hp-unload
----

Tools, which are in hplip-gui:

----
hp-check
hp-print
hp-systray
hp-toolbox
hp-devicesettings
hp-faxsetup
hp-linefeedcal
hp-makecopies
hp-printsettings
hp-wificonfig
----

=== HP printer isn't discovered, doesn't print or doesn't print well

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:

----
hp-setup -i -g
----

for interactive mode, or:

----
hp-setup -g
----

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 [command]`hp-setup`, if it helps. If it doesn't help, please file a bugzilla, attach output of hp-setup and mention that you tried [command]`hp-setup`.

=== Device which needs plugin does not work after HPLIP update

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:

----
$ hp-plugin -i
----

=== Devices which require a binary plugin stopped to work on Fedora Silverblue/CoreOS

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.

== golang-github-openprinting-ipp-usb

=== USB printer/scanner doesn't work due a conflict on USB port

*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_ and start using the one from *ipp-usb* (as a xref:cups-terminology.adoc#_temporary_print_queues[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.

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 [filename]`/var/log/ipp-usb/` directory at https://bugzilla.redhat.com[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. See [command]`man ipp-usb`.

== sane-airscan

=== There are less options available if the device is discovered by sane-airscan than with a classic driver

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 https://bugzilla.redhat.com[bugzilla] with logs.