Bug 1150323

Summary: Better detection of networked all-in-one printer
Product: [Fedora] Fedora Reporter: Luya Tshimbalanga <luya>
Component: hplipAssignee: Zdenek Dohnal <zdohnal>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 22CC: jpopelka, twaugh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 20:29:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Luya Tshimbalanga 2014-10-07 23:02:01 UTC
Description of problem:
Setting up a networked HP all-in-one printer using settings in Gnome Shell is easy but left the ability to use the scanner feature when using the dnssd for uri rather than hp:\ protocol. I don't know if the case also applies to other desktop environments.

Version-Release number of selected component (if applicable):
1.7.5-5

How reproducible:
Always

Steps to Reproduce:
1. Set up a networked HP all-in-work printer
2.
3.

Actual results:
Only the printer part works. simple-scan failed to detect networked scanner part.

Expected results:
All functions work as intended without manual intervention

Additional info:
CUPS uses dnssd for detecting a networked printer. It recognized a networked all-in-one printer then assign the correct uri, in this example, hp:/net/Photosmart_eStn_C510_series?ip=192.168.1.67 . It seems dnssd cannot use hp:/ protocol.

Comment 1 Jiri Popelka 2014-10-08 07:31:06 UTC
*** Bug 1150319 has been marked as a duplicate of this bug. ***

Comment 2 Tim Waugh 2014-10-08 08:11:53 UTC
Policy about which device URI to use for a queue comes from system-config-printer.

(In reply to Luya Tshimbalanga from comment #0)
> It seems dnssd cannot use hp:/ protocol.

This isn't quite right. The real issue is that libsane-hpaio only finds queues with hp:/ device URIs.

The question remains whether libsane-hpaio should interrogate other backends, or whether system-config-printer should use hp:/ device URIs when applicable (probably the latter).

It's a shame that we have to do some special-case handling either way.

Comment 3 Luya Tshimbalanga 2014-10-09 04:39:30 UTC
(In reply to Tim Waugh from comment #2)
> Policy about which device URI to use for a queue comes from
> system-config-printer.

> The question remains whether libsane-hpaio should interrogate other
> backends, or whether system-config-printer should use hp:/ device URIs when
> applicable (probably the latter).
> 
> It's a shame that we have to do some special-case handling either way.

Thank you for the explanation about the problem related to libsane-hpaio. I don't know if it will be possible to address that to HP themselves.

Comment 4 Tim Waugh 2014-10-17 12:39:32 UTC
So, configuring the queue using system-config-printer results in the hp: URI being used, as it already prefers hp: URIs to dnssd: URIs. However, in order to have an hp: URI to compare against it needs to run a special command (hp-makeuri) if it thinks this is an HP printer.

This is pretty ridiculous. The correct answer is for HPLIP to perform proper network detection in its backend, or in another backend it provides.

Comment 5 Luya Tshimbalanga 2014-10-18 18:33:26 UTC
Too bad hplip relies on special command. Is it possible to for it using standard command? Once the fix will come, I am willing to test the network detection for all-in-one printer.

Comment 6 Luya Tshimbalanga 2015-06-17 16:25:22 UTC
I am reopening this bug because the issue is still present in all version of hplip (including Rawhide) which still uses dnssd rather than hp:/net. Launchpad bugreport remained inactive with no proper patch or fixes :(

Comment 7 Fedora Admin XMLRPC Client 2016-06-24 10:36:56 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Fedora End Of Life 2016-07-19 20:29:25 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.