Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1029979

Bug#972898: hplip: no network scanner detection with 3.20.9

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Package: hplip
Version: 3.20.9+dfsg0-4
Severity: important
Tags: patch

Dear Maintainer,

hplip version 3.20.9 replaced the custom mDNS implementation for scanner discovery (protocol/discovery/mdns.c) with using avahi (protocol/discovery/avahiDiscovery.c).
While this is a welcome change in principle, unfortunately the new code does not work.

The main problem is that it does not wait until all callbacks are called before stopping via avahi_simple_poll_quit.
Thus there is a 50/50 chance whether the '_scanner._tcp.local' or the '_uscan._tcp.local' mDNS reply gets processed (in the browse_callback) and it is practically impossible that any scanner gets processed (in the resolve_callback), because avahi_simple_poll_quit is called when the first mDNS reply has been processed.
It seems like this code was never really tested with an actual scanner on the network.

Attached is a patch fixing this by implementing a check_terminate function similar to the one used by avahi-browse.

The second problem is that the code expects the 'ty' part of the mDNS reply, which contains the device name, to start with 'HP'. However this is not always the case.
Previous versions of hplip would simply remove the first three letters of the scanner name and continue, which could be worked around by also removing these three letters in the models.dat. That issue has been reported two years ago upstream without response from HP. (see: https://bugs.launchpad.net/hplip/+bug/1797501)
The new code however  discards the scanner if its 'ty' name does not start with 'HP', breaking that workaround.
Fortunately, since the new code now uses avahi, a proper fix is relatively simple: If the 'ty' part of the mDNS response does not start with 'HP', check whether the 'mfg' part does.

The second attached patch implements this fix.

While debugging this I also noticed that the log level for one message is wrong, causing spurious errors to be reported.

The third attached patch changes the log level for this message from BUG to DBG to fix this.

I hope HP solves this eventually, but until then please include these patches in the Debian package, so that scanner detection works again.

Thanks in advance,
Ahzo

PS: I tried to report this upstream, but my Launchpad login attempts always fail, because "something just went wrong in Launchpad".

Back to linux.debian.bugs.dist | Previous | Next — Next in thread | Find similar

Thread

Bug#972898: hplip: no network scanner detection with 3.20.9 Ahzo <ahzo@tutanota.com> - 2020-10-25 23:00 +0100
  Bug#972898: hplip: no network scanner detection with 3.20.9 Brian Potkin <claremont102@gmail.com> - 2020-10-26 16:10 +0100
    Bug#972898: hplip: no network scanner detection with 3.20.9 Ahzo <ahzo@tutanota.com> - 2020-10-27 23:10 +0100

csiph-web