FAQ os conditions

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.

Some probes failed to send so results incomplete 

This can happen in some IPv6 scans when the local firewall causes a send to fail.

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."