MDNS protocol incorrectly parses type response

Bug #1797501 reported by Jeremy Kerr on 2018-10-12
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
HPLIP
Undecided
Unassigned

Bug Description

I have an OfficeJet 6500, connected over the network. After updating to bionic (3.17.10+repack0-5), this scanner is no longer found by the cups infrastructure.

When running a 'scanimage -L', I get the following in the journal:

    io/hpmud/model.c 532: no icejet_6500_e710n-z attributes found in /usr/share/hplip/data/models/models.dat

- indeed, there is no "icejet_6500_e710n-z" section in models.dat; it looks like we've lost the first three characters there ("Off").

The mdns txt response from the printer looks fine, including proper model and type fields:

 [jk@pecola hplip]$ avahi-browse -r _scanner._tcp
+ br0 IPv4 Officejet 6500 E710n-z [55F97F] _scanner._tcp local
= br0 IPv4 Officejet 6500 E710n-z [55F97F] _scanner._tcp local
   hostname = [officejet.local]
   address = [192.168.0.155]
   port = [9500]
   txt = ["feeder=T" "flatbed=T" "button=T" "note=" "adminurl=http://officejet.local." "mdl=Officejet 6500 E710n-z" "mfg=HP" "ty=Officejet 6500 E710n-z" "txtvers=1"]

The actual TXT section that mdns_parse_respponse() is parsing is:

  "txtvers=1\031ty=Officejet 6500 E710n-z\006mfg=HP\032mdl=Officejet 6500 E710n-z adminurl=http://officejet.local.\005note=\bbutton=T\tflatbed=T\bfeeder=T"

However, it looks like there's a bug in mdns_readMDL(), where we parse the 'ty' field:

        if (strncmp(p, "mdl=", 4) == 0)
        {
           z = 4;
        }
        else if (strncmp(p, "ty=", 3) == 0)
        {
           z = 3+3;
        }

mdl= parsing looks fine. However, for that second case, we skip over the 'ty=' description, plus another three bytes.

In my case, those three bytes are the "Off" part of the type name, leaving just "icejet 6500 E710n-z" as the type, which doesn't match anything in models.dat.

I see that this code is the same in the latest (3.18) release.

brian_p (claremont102) wrote :

Why is my ENVY4500 not affected by this?

brian@desktop:~$ scanimage -L
device `hpaio:/net/envy_4500_series?ip=192.168.7.235&queue=false' is a Hewlett-Packard envy_4500_series all-in-one

The code in mdns.c is the same as what you quoted.

--
Brian.

Jeremy Kerr (jk-ozlabs) wrote :

Hi Brian,

If I were to take a guess, I'd say that the MDNS response has a mdl= descriptor only, or the response has the mdl= descriptor before the ty= descriptor. Or it could be that you're not using the mdns query at all (ie, discovering the scanner through CUPS instead).

If you query the device directly, that should help determine what's happening there. You can do that with:

    $ avahi-browse -r _scanner._tcp

brian_p (claremont102) wrote :

Hi Jeremy,

The output of your command is

= eth0 IPv4 ENVY4500 _scanner._tcp local
   hostname = [envy4500.local]
   address = [192.168.7.235]
   port = [8080]
   txt = ["flatbed=T" "button=T" "UUID=1c852a4d-b800-1f08-abcd-308d99fafac2" "note=Upstairs" "adminurl=http://envy4500.local." "mdl=ENVY 4500 series" "mfg=HP" "ty=ENVY 4500 series" "txtvers=1"]

For completeness: $ avahi-browse -r _uscan._tcp

= eth0 IPv4 ENVY4500 _uscan._tcp local
   hostname = [envy4500.local]
   address = [192.168.7.235]
   port = [8080]
   txt = ["duplex=F" "is=platen" "cs=binary,color,grayscale" "rs=/eSCL" "representation=" "UUID=1c852a4d-b800-1f08-abcd-308d99fafac2" "note=Upstairs" "adminurl=http://envy4500.local." "ty=HP ENVY 4500 series" "pdl=application/octet-stream,application/pdf,image/jpeg" "vers=2.0" "txtvers=1"]

The device is discovered via its Bonjour broadcasts.

--
Brian.

Jeremy Kerr (jk-ozlabs) wrote :

Hi Brian,

Given your mdns responses, it looks like the query on _scanner._tcp would fail too, as the first three bytes of the "ty=" TXT record are skipped, giving "Y 4500 series". Do you see any failure in the logs from that?

However, your _uscan._tcp response would be OK; as it has this:

   "ty=HP ENVY 4500 series"

so that +3 skips over the "HP " characters; which would match the entry in models.dat:

  [envy_4500_series]

I'm assuming that the _uscan._tcp response is the one that allows the mdns discovery code to pick up your scanner.

I don't see any responses for the _uscan service from my device, only _scanner.

  [jk@pecola ~]$ avahi-browse -tr _uscan._tcp
  [jk@pecola ~]$ avahi-browse -tr _scanner._tcp
  + br0 IPv4 Officejet 6500 E710n-z [55F97F] _scanner._tcp local
  = br0 IPv4 Officejet 6500 E710n-z [55F97F] _scanner._tcp local
     hostname = [officejet.local]
     address = [192.168.0.155]
     port = [9500]
     txt = ["feeder=T" "flatbed=T" "button=T" "note=" "adminurl=http://officejet.local." "mdl=Officejet 6500 E710n-z" "mfg=HP" "ty=Officejet 6500 E710n-z" "txtvers=1"]

brian_p (claremont102) wrote :

Hi Jeremy,

As I said - 'scanimage -L' is fine and I see nothing of the issue you are experiencing elsewhere. You have provided quite a bit of analysis which I cannot add to. The only people who could comment significantly are upstream hplip. Perhaps someone will come along?

--
Brian.

Jeremy Kerr (jk-ozlabs) wrote :

Hi Brian,

Yep, I'd expect `scanimage -L` to work for you, as you'd get a valid parse from the _uscan._tcp response. And yes, would be good to get a comment from upstream :)

brian_p (claremont102) wrote :

I can now reproduce the behaviour described in Jeremy's first post.

The file /etc/avahi/services/example.service was created:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">Scanner on %h</name>
  <service protocol="ipv4">
    <type>_scanner._tcp</type>
    <domain-name>local</domain-name>
    <host-name>desktop.local</host-name>
    <port>10200</port>
    <txt-record>txtvers=1</txt-record>
    <txt-record>ty=Officejet 6500 E710n-z</txt-record>
    <txt-record>mfg=HP</txt-record>
    <txt-record>mdl Officejet 6500 E710n-z</txt-record>
    <txt-record>button=T</txt-record>
    <txt-record>flatbed=T</txt-record>
    <txt-record>feeder=T</txt-record>
  </service>
</service-group>

This gives me the same avahi-browse output as he got and the scanner is not detected for the reason given. Interchanging the lines with ty amd mdl does see device detection taking place.

--
Brian.

brian_p (claremont102) wrote :

Another affected device:

  = wlp2s0 IPv4 HP DeskJet 3630 series [61C73D] _uscan._tcp
        local
     hostname = [HP18602461C73D.local]
     address = [192.168.1.129]
     port = [8080]
     txt = ["duplex=F" "is=platen" "cs=binary,color,grayscale" "rs=eSCL"
  "representation=images/printer.png"
  "UUID=1c852a4d-b800-1f08-abcd-18602461c73d" "mopria-certified=1.3" "note="
  "adminurl=http://HP18602461C73D.local." "ty=DeskJet 3630 series"
  "pdl=application/octet-stream,application/pdf,image/jpeg" "vers=2.5"
  "txtvers=1"]

Is there a target number of devices to reach before action is taken to fix this issue? :)

--
Brian.

brian_p (claremont102) wrote :

Almost certainly another one. An HP Laserjet PRO MFP M280nw. See

https://bugs.launchpad.net/hplip/+bug/1814307

Messages #9 and #21.

--
Brian.

brian_p (claremont102) wrote :

A new entry for the Hall of Fame:

https://bugs.launchpad.net/hplip/+bug/1816226

Message #13 in particular.

brian_p (claremont102) wrote :

Let's start with Jeremy Kerr's first message in this report. I have no understanding of python but, from observation and a bit of testing, it has all the hallmarks of being a correct analysis. And then there are quite a number of bug reports that appear to arise from the change in mdns.c which occured in HPLIP 3.17.10.

Not a word from HPLIP upstream in four months. Maybe they are on an extended Christmas holiday or taking an early summer vacation. :)

All that needs to be said, perhaps, is that this code will not changed and it is absolutely what is required for a modern HPLIP. That would be upfront and we could then deal with its fallout. Not ideal, but we would know where we were up to.

Of course, it is always possible that any bugs are in printer firmware. After all, why should my ENVY4500 give a _uscan._tcp entry

  ty=HP ENVY 4500 series

which will fit what is in models.dat. But an MFP M278-M281 returns

  ty=HP ColorLaserJet MFP M278-M281

which has no tag in models.dat.

Or a DeskJet 3630 series, which has

  ty=DeskJet 3630 series

Looking for kJet 3630 series in models.dat is pointless.

So what is it? Software bug? Firmware bug? A bit of both?

It is not just the existence of the bug which is the issue, it is the complete silence regarding it. HPLIP is quality software. Cannot we keep it in that condition?

--
Brian.

brian_p (claremont102) wrote :

Losing track: have we had the HP LaserJet Pro MFP M28-M31?

https://bugs.launchpad.net/hplip/+bug/1821932

Jan Vlug (jan-vlug) wrote :

Regarding the M281fdw LaserJet:

I have the strong impression that this issue is now fixed for Fedora in hplip-3.18.12-9.fc29.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1694663

Note that the installation of the HP plugin is also required to make this scanner work.

brian_p (claremont102) wrote :

To reduce the amount of typing for me, I will reference Message #5 at

https://bugs.launchpad.net/hplip/+bug/1824659

Unless there have further changes, it doesn't do much for ty=Officejet 6500 E710n-z.

--
Brian.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.