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.
Why is my ENVY4500 not affected by this?
brian@desktop:~$ scanimage -L
device `hpaio:
The code in mdns.c is the same as what you quoted.
--
Brian.