I'm trying to do some Nmap OS detection and I'm running into some results I don't understand.

The scan I'm running is the following:

nmap -O -F -v -T2 -oA nmap-uphosts-OSdetect -iL  < my_in_file

I've got -F in there to limit the number of ports because the scan of 40 hosts was taking really long with the default 1000 ports. The -T2 because there seemed to be some IDS / rate limiting / reactive firewall type defenses when running it at full speed.

When my scan completes pretty much every single host has the following message in the results:


This occurs even on hosts with multiple open & closed ports, as required for OS detection.

It's worth noting that all of the hosts are VMWare VMs. I'm not sure if this results in a fingerprint that Nmap has a little more trouble digesting.

Does anyone have any insight on what might be the cause & how I can determine specifically which test conditions are non-ideal to try and get more conclusive results? As it is all the hosts list several possible OSes without a conclusive ID.


EDIT - To clarify this is a lab / learning environment. I have permission to run the scans.


Nmap fingerprints a remote system's operating system (more correctly, the OS's TCP/IP stack) by sending a series of probes and measuring the responses. These probes check for particular choices that the OS programmers made when implementing parts of the Internet protocols that are not as strictly defined as other parts.

There are several reasons why Nmap considers an OS fingerprint non-ideal, and it can be useful to know what they are and why they matter:

  • Scan delay is greater than 500ms - Nmap sends six probes in quick succession and checks to see how much the remote system increments certain counters. If there is too much delay between packets, then there's too good of a chance that someone else's packets were incrementing the counters instead. (-T2 sets a scan delay of 400ms)
  • Timing level 5 (Insane) used - -T5 can overwhelm a system or its network link, causing dropped packets and unpredictable responses, which lead to an unusable fingerprint.
  • Missing an open/a closed TCP port so results incomplete - Some probes are only sent to open ports, and some only to closed ports, so without one or the other, the fingerprint cannot be complete.
  • Host distance appears to be negative - This is a weird thing that can happen when a firewall is sending responses to blocked UDP ports. Any time a firewall sends a response to one of Nmap's probes, it makes the fingerprint less likely to match, since the responses will be a mix of good and fake.
  • Host distance is greater than five - The farther away you are from the target, the more likely there is some sort of packet filter or traffic shaper that is causing interference with Nmap's probes. Also, some of the timing stuff can be thrown off.
  • maxTimingRatio is greater than 1.4 - This is a measure of responsiveness to Nmap's probes. Nmap tries to send one probe every 100ms, for a total of 500ms between the first and the 6th probe. If it has to wait too long for any of them and the 6th probe is sent more than 700ms after the first, then we assume the timing checks won't be accurate.
  • Didn't receive UDP response. Please try again with -sSU - One of the probes sent is to a closed UDP port. If you didn't scan for UDP, then your fingerprint will be incomplete.

These reasons came from the Nmap source code, but you can see them when you run a scan with -v2 or -d.

Please note that "non-ideal" doesn't necessarily mean that you won't get an accurate fingerprint match. It just means that the chances are good that something will have interfered and caused a poor-quality fingerprint. In these cases, Nmap will not print an OS fingerprint for submission, since we don't want to clutter up the database with fingerprints that are "blurry."

  • Thanks for this. Good info, I reran the scan but without the -F option and sure enough when it completed the output for each individual host contained the following message: OS fingerprint not ideal because: maxTimingRatio (1.489200e+02) is greater than 1.4 Are there nmap options I ought to tweak to address this? Or is this purely a result of the latency on the network? I'm connected by VPN to a lab environment. My internet connection is on the low end of the spectrum for home internet these days(5Mbps) but I was figuring that would still be plenty fast for these types of tools. – MTLPhil Jul 27 '14 at 15:08
  • Ahh, I see you mention the -T2 option affecting the scan delay. Perhaps I ought to get rid of that. It seemed like when I ran the scan without it though I was getting a lot of messages about dropped packets but maybe I mistakenly correlated that with the scan speed / aggressiveness. – MTLPhil Jul 27 '14 at 15:10
  • 1
    @MTLPhil maxTimingRatio problems are most likely due to network latency or congestion. VPN is a likely culprit. Nmap usually adapts to network conditions quite well, but one adaptation is slowing down, so your probes may be sent too far apart to be useful for OS detection. Timing options like -T2 are discussed here and the official Nmap book has deep discussion of Nmap's internal timing algorithms. – bonsaiviking Jul 28 '14 at 12:19
  • Thanks for your comment & info. My latency to the target machines over the VPN is generally in the 100ms - 150ms range, sometimes higher but usually around that When using the --osscan-guess option I'm still getting some useful info. A list of guesses with percentages, usually all pretty close to each other (ie. all Linux but different kernel versions). – MTLPhil Jul 29 '14 at 20:34

Your Answer

