Some OS fingerprints match too easily because they are missing some probes

[dmiller-nmap]

Some fingerprints in nmap-os-db look like this:

Fingerprint Cisco Wireless IP Phone 7920-ETSI
Class Cisco | embedded || VoIP phone
CPE cpe:/h:cisco:unified_wireless_ip_phone_7920
SEQ(R=N)
OPS(R=N)
WIN(R=N)
ECN(R=N)
T1(R=N)
T2(R=N)
T3(R=N)
T4(R=Y%DF=N%T=3B-45%TG=40%W=4000%S=A|O%A=Z%F=R%O=%RD=0%Q=)
T5(R=Y%DF=N%T=3B-45%TG=40%W=0%S=Z%A=O|S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=N%T=3B-45%TG=40%W=0%S=A|O%A=Z%F=R%O=%RD=0%Q=)
T7(R=Y%DF=N%T=3B-45%TG=40%W=0%S=Z%A=O|S%F=AR%O=%RD=0%Q=)
U1(DF=N%T=3B-45%TG=40%IPL=38%UN=0%RIPL=G%RID=4210%RIPCK=Z%RUCK=G%RUD=G)
IE(DFI=S%T=3B-45%TG=40%CD=S)

In particular, the SEQ, OPS, and WIN tests are missing any response. In the MatchPoints section, the other tests give a weight to whether the response is received or not (the R subtest), but these open-TCP-port tests don't. Because of this, any target observation will score a better match against these fingerprints than against another that does contain values for each of the subtests in these lines.

I am not sure whether we need to address this or not: the false matches are never exact matches, so they only show up when using --osscan-guess. But it may be worth changing how the matches are scored or removing these fingerprints in favor of more complete ones. At least we could document what is supposed to happen in this case.