When running NMAP on a host, the command returns its predictions by order. It is ordered by the "accuracy" attribute in one of the tags sent back form the command.

When we parse NMAP result using the XML parser, it doesn't necessarily keep the same order as the input, causing lower accuracy results to be on the first rows on the created table.

Since the pattern uses the first row of the parsed table, it might not be the best match for the discovered CI "accuracy" attribute must be parsed as part of the command (NMAP Java code), and pattern must take "accuracy" into account when choosing the class for the discovered CI.

For example - A Linux machine was discovered as Windows (96 as accuracy), even though Linux was with higher accuracy (99)

NMAP response example:

<!DOCTYPE nmaprun>
<?xml-stylesheet href="file:///C:/TrackDisco/agent/nmap/nmap.xsl" type="text/xsl"?>
<!-- Nmap 7.50 scan initiated Sun May 27 13:49:07 2018 as: C:\\TrackDisco\\agent\\nmap\\nmap.exe -Pn -PS -PA -O -p 21,22,23,25,53,80,110,111,135,137,139,161,162,199,389,427,443,445,515,548,631,636,993,1414,1443,1521,2049,3306,5060,5432,5480,5666,5989,7001,7500,8080,9080,9100,9443,10000,50000 -&#45;datadir C:\\TrackDisco\\agent\\nmap\\safeScripts -oX - -T4 -v -Pn -r -&#45;reason -&#45;system-dns -->
<nmaprun scanner="nmap" args="C:\\TrackDisco\\agent\\nmap\\nmap.exe -Pn -PS -PA -O -p 21,22,23,25,53,80,110,111,135,137,139,161,162,199,389,427,443,445,515,548,631,636,993,1414,1443,1521,2049,3306,5060,5432,5480,5666,5989,7001,7500,8080,9080,9100,9443,10000,50000 -&#45;datadir C:\\TrackDisco\\agent\\nmap\\safeScripts -oX - -T4 -v -Pn -r -&#45;reason -&#45;system-dns" start="1527425347" startstr="Sun May 27 13:49:07 2018" version="7.50" xmloutputversion="1.04">
<scaninfo type="syn" protocol="tcp" numservices="41" services="21-23,25,53,80,110-111,135,137,139,161-162,199,389,427,443,445,515,548,631,636,993,1414,1443,1521,2049,3306,5060,5432,5480,5666,5989,7001,7500,8080,9080,9100,9443,10000,50000"/>
<verbose level="1"/>
<debugging level="0"/>
<taskbegin task="System DNS resolution of 1 host." time="1527425347"/>
<taskend task="System DNS resolution of 1 host." time="1527425352"/>
<taskbegin task="SYN Stealth Scan" time="1527425352"/>
<taskend task="SYN Stealth Scan" time="1527425353" extrainfo="41 total ports"/>
<host starttime="1527425352" endtime="1527425360"><status state="up" reason="user-set" reason_ttl="0"/>
<address addr="" addrtype="ipv4"/>
<ports><extraports state="closed" count="40">
<extrareasons reason="resets" count="40"/>
<port protocol="tcp" portid="22"><state state="open" reason="syn-ack" reason_ttl="128"/><service name="ssh" method="table" conf="3"/></port>
<os><portused state="open" proto="tcp" portid="22"/>
<portused state="closed" proto="tcp" portid="21"/>
<osmatch name="Actiontec MI424WR-GEN3I WAP" accuracy="99" line="1307">
<osclass type="WAP" vendor="Actiontec" osfamily="embedded" accuracy="99"><cpe>cpe:/h:actiontec:mi424wr-gen3i</cpe></osclass>
<osclass type="WAP" vendor="Linux" osfamily="Linux" accuracy="99"><cpe>cpe:/o:linux:linux_kernel</cpe></osclass>
<osmatch name="DD-WRT v24-sp2 (Linux 2.4.37)" accuracy="98" line="42324">
<osclass type="general purpose" vendor="Linux" osfamily="Linux" osgen="2.4.X" accuracy="98"><cpe>cpe:/o:linux:linux_kernel:2.4.37</cpe></osclass>
<osmatch name="Linux 3.2" accuracy="98" line="61486">
<osclass type="general purpose" vendor="Linux" osfamily="Linux" osgen="3.X" accuracy="98"><cpe>cpe:/o:linux:linux_kernel:3.2</cpe></osclass>
<osmatch name="Microsoft Windows XP SP3 or Windows 7 or Windows Server 2012" accuracy="96" line="80502">
<osclass type="general purpose" vendor="Microsoft" osfamily="Windows" osgen="XP" accuracy="96"><cpe>cpe:/o:microsoft:windows_xp::sp3</cpe></osclass>
<osclass type="general purpose" vendor="Microsoft" osfamily="Windows" osgen="7" accuracy="96"><cpe>cpe:/o:microsoft:windows_7</cpe></osclass>
<osclass type="general purpose" vendor="Microsoft" osfamily="Windows" osgen="2012" accuracy="96"><cpe>cpe:/o:microsoft:windows_server_2012</cpe></osclass>
<osmatch name="Linux 4.4" accuracy="96" line="64088">
<osclass type="general purpose" vendor="Linux" osfamily="Linux" osgen="4.X" accuracy="96"><cpe>cpe:/o:linux:linux_kernel:4.4</cpe></osclass>
<osmatch name="Microsoft Windows XP SP3" accuracy="96" line="80207">
<osclass type="general purpose" vendor="Microsoft" osfamily="Windows" osgen="XP" accuracy="96"><cpe>cpe:/o:microsoft:windows_xp::sp3</cpe></osclass>
<osmatch name="BlueArc Titan 2100 NAS device" accuracy="91" line="9925">
<osclass type="storage-misc" vendor="BlueArc" osfamily="embedded" accuracy="91"><cpe>cpe:/h:bluearc:titan_2100</cpe></osclass>
<tcpsequence index="256" difficulty="Good luck!" values="C03FD1E0,F0633E3B,78C0A12,5BFF4F41,A549AE3B,476A25B8"/>
<ipidsequence class="Incremental" values="3CD1,3CD2,3CD3,3CD4,3CD5,3CD6"/>
<tcptssequence class="none returned (unsupported)"/>
<times srtt="188432" rttvar="55137" to="408980"/>
<runstats><finished time="1527425360" timestr="Sun May 27 13:49:20 2018" elapsed="14.16" summary="Nmap done at Sun May 27 13:49:20 2018; 1 IP address (1 host up) scanned in 14.16 seconds" exit="success"/><hosts up="1" down="0" total="1"/>

Steps to Reproduce

  1. Enable Credentialless discovery at the global level from
    • https://<instancename>
  2. Trigger quick discovery against a CI
  3. The resulting discovery run ends up classifying the CI with the wrong server class derived from the base class

For example, a vCenter server running on Suse Linux, with credentialless discovery enabled fails to classify the CI as a vCenter CI, and classifies it as a cmdb_ci_linux_server. Disabling credentialless discovery and running quick discovery again returns the correct classification. 


This issue has been fixed. If you are able to upgrade, review the Fixed In or Intended Fix Version fields to determine whether any versions have a planned or permanent fix.

Related Problem: PRB1284233

Seen In

There is no data to report.

Fixed In

Kingston Patch 8

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-08-20 03:28:47