MDNS protocol incorrectly parses type response
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HPLIP |
New
|
Undecided
|
Unassigned |
Bug Description
I have an OfficeJet 6500, connected over the network. After updating to bionic (3.17.10+
When running a 'scanimage -L', I get the following in the journal:
io/
- indeed, there is no "icejet_
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://
The actual TXT section that mdns_parse_
"txtvers=
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 /net/envy_ 4500_series? ip=192. 168.7.235& queue=false' is a Hewlett-Packard envy_4500_series all-in-one
device `hpaio:
The code in mdns.c is the same as what you quoted.
--
Brian.