Previously they were a flat list intermixing human-readable names and
CPE strings. Now they reflect the structure that we use to represent
them. In brief:
host.os = {
{
name = "Microsoft Windows XP",
classes = {
{
vendor = "Microsoft",
osfamily = "Windows",
osgen = "XP",
type = "general purpose",
cpe = {
"cpe:/o:microsoft:windows_xp"
}
},
... more classes ...
},
},
... more OS matches ...
}
o Fixed an error where very long long messages could cause an
assertion failure: "log_vwrite: vsnprintf failed. Even after
increasing bufferlen to ---, Vsnprintf returned -1 (logt == 1)."
This was reported by David Hingos.
o Fixed an assertion failure that was printed when a fatal error
occurred while an XML tag was incomplete: "!xml.tag_open, file
..\xml.cc, line 401". This was reported by David Hingos.
This is part of the error handler that attempts to close open XML tags
at a fatal error. The case wasn't handled where a fatal error happened
while a start tag was still open (didn't have its '>' written yet). This
came from a bug report from David Hingos.
http://seclists.org/nmap-dev/2012/q1/514
This avoids a failure when writing long strings on Windows. Previously
we tried only one reallocation of the write buffer, and panicked if that
failed.
http://seclists.org/nmap-dev/2012/q1/514
We use as features even the four reserved TCP flags (some of them are no
longer reserved but declared for a particular purpose by some RFCs).
getFlags only returns 8 bits, leading to garbage in the feature vector
in the higher-order positions.
This doesn't affect the integrity of fingerprint submissions, because
they copy the packet contents directly and don't go through the getFlags
accessor.
We use printno < num_prefect_matches rather than accuracy[printno] ==
1.0. In IPv4 classification, the two are equivalent, but IPv6
classifications are never fully 100%. This was causing only the first OS
class and CPE to be shown for IPv6 matches.
The lack of this was causing PCAP_IS_SUITABLE to fail on Arch Linux, at
least. I think that in some cases this caused both -L../libpcap and
-lpcap to be added to the linker line, which could cause an error
because of the need to link with -lnl. (We check for -lnl when
--with-libpcap=included is used (since r23163), but the PCAP_IS_SUITABLE
failure went around this check and allowed linking with the included
libpcap without checking whether -lnl is required.)
Here are reported build failures and responses:
http://seclists.org/nmap-dev/2011/q3/449http://seclists.org/nmap-dev/2011/q4/33http://seclists.org/nmap-dev/2012/q1/369
