A few more mentions of this:

• http://seclists.org/nmap-dev/2016/q4/156
• https://www.reddit.com/r/nmap/comments/5iq54n/need_help_discovering_active_clients_with_nmap/

Both of these mention android phones as being the missing devices, but the original report was for an HP printer. I wonder if timing is the culprit? If we slowed down or took a little more time to allow the ARP scan to complete, would we catch these devices?

Did some research, so here are some links:

• Report from 2009 that Nmap 4.62 misses printers that Nmap 4.11 always sees: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535441
• Commit from 2012 that discusses issues with missing packets in libpcap on Solaris: 5008078
• Long-standing issue to update our libpcap calls to a more modern flow: Modernize Nmap's pcap_* API usage #123

I seem to have run into the same issue, as written down in this Stack Exchange question

It sounds like my issue on Information Security Stack Exchange: Inconsistent list of hosts found by nmap pings from scan to scan - tcpdump shows ICMP echo replies did arrive is an instance of this issue.

Here I show the output from two scans and the corresponding tshark trace from them. For the host in question, the tshark data for the two scans is identical, but the nmap output for some reason shows the host up in one scan and down in the other.

So in my case, nmap reports the host as down, even though tcpdump/tshark shows an ICMP Echo reply was received. (I think) the received ICMP Echo reply implies that this is not an ARP problem, so perhaps this really is a separate issue. But one more related data point at least.

If anybody conclusively can show that this is a separate issue, I'd be happy to file a separate issue for my issue above. Just let me know.

For my particular case, the problem was the -PE option to nmap. If I run nmap with the -PE option, it finds inconsistent results in about 1/3 of runs, whereas without -PE it is consistent over several 1000s of runs.

So we just stopped using -PE.

This also means that my problem probably wasn't related to the other posts in this issue. Sorry for the noise.

I have the same problem with nmap 7.6 on Ubuntu 18.04 and I am not using -PE; see https://serverfault.com/questions/956806/regular-nmap-scan-flaky-hosts-are-missing-sometimes

The hosts that are missing change from time to time; they are not always exactly the same.

$ nmap --version
Nmap version 7.60 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.0g nmap-libssh2-1.8.0 libz-1.2.8 libpcre-8.39 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

I just ran into this today when scanning an address space. Adding --disable-arp-ping got me all the hosts.

Interestingly, without disable-arp-ping, I got the same amount of hosts whether sudo or not. So there were actually 14 hosts up, but if I omited disable-arp-ping I only found 7 with sudo and 7 when not sudo.

Nmap version 7.60 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.0g nmap-libssh2-1.8.0 libz-1.2.8 libpcre-8.39 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

My problem is described on this post:

https://security.stackexchange.com/questions/211907/nmap-not-showing-all-live-hosts

I was told to post it here the example is in the description...

And from my tests what I have concluded is that the problem is in when arp requests are sent to the entire local net 192.168.0.1/24... Adding the option - - disable-arp-ping also solved my issue

Same issue here:

Environment

root@gslab:~/scan# uname -a
Linux gslab 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

root@gslab:~/scan# nmap --version

Nmap version 7.60 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.0g nmap-libssh2-1.8.0 libz-1.2.8 libpcre-8.39 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Input files

One file has 10 hosts, the other has 11 hosts:

root@gslab:~/scan# diff -c  11_host.txt 10_host.txt
*** 11_host.txt 2020-02-06 11:35:34.447408421 +0000
--- 10_host.txt 2020-02-06 11:35:45.687494164 +0000
***************
*** 8,11 ****
  10.155.193.19
  10.155.193.20
  10.155.193.21
- 10.155.193.29
--- 8,10 ----

10 hosts

root@gslab:~/scan# nmap  -sS  --top-ports 1 -iL 10_host.txt | grep "report for" -c
10

11 hosts

root@gslab:~/scan# nmap  -sS  --top-ports 1 -iL 11_host.txt | grep "report for" -c
10

When the list contains 11 hosts, the first one is skipped.

tcpdump

We can see an ARP req/resp for both hosts, but we ignore the response for the first one and send a second arp req:

root@gslab:~/scan# tcpdump -veenr /var/tmp/nmap.pcap -s0 arp
reading from file /var/tmp/nmap.pcap, link-type EN10MB (Ethernet)
12:15:32.661573 00:50:56:86:2e:50 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.155.193.11 tell 10.155.193.1, length 28
12:15:32.662294 00:50:56:86:36:64 > 00:50:56:86:2e:50, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.155.193.11 is-at 00:50:56:86:36:64, length 46
12:15:32.849134 00:50:56:86:2e:50 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.155.193.10 tell 10.155.193.1, length 28
12:15:32.850265 00:50:56:86:6b:7d > 00:50:56:86:2e:50, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.155.193.10 is-at 00:50:56:86:6b:7d, length 46
12:15:32.949309 00:50:56:86:2e:50 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.155.193.10 tell 10.155.193.1, length 28
12:15:32.950463 00:50:56:86:6b:7d > 00:50:56:86:2e:50, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.155.193.10 is-at 00:50:56:86:6b:7d, length 46

switching order

If i switch the first two hosts in the file, I get the same result:

root@gslab:~/scan# head -n2 11_host.txt
10.155.193.11
10.155.193.10
root@gslab:~/scan# nmap  -sS  --top-ports 1 -iL 11_host.txt | grep "report for" -c
10
root@gslab:~/scan# nmap  -sS  --top-ports 1 -iL 11_host.txt | grep "report for"
Nmap scan report for 10.155.193.11
Nmap scan report for 10.155.193.12
Nmap scan report for 10.155.193.13
Nmap scan report for 10.155.193.14
Nmap scan report for 10.155.193.15
Nmap scan report for 10.155.193.18
Nmap scan report for 10.155.193.19
Nmap scan report for 10.155.193.20
Nmap scan report for 10.155.193.21
Nmap scan report for 10.155.193.29

We're marking this done as of Nmap 7.90. We made several interesting improvements, but the big fix is in 875a51f. Thanks everyone for your help in diagnosing the problem!

Unfortunately, the changes here were insufficient to accommodate all targets. Here are some observations:

1. ARP requests are broadcast, so each probe is seen by every endpoint. Scanning more hosts in parallel does not slow down the probes sent to any individual target.
2. Some network equipment (Cisco, HPE, Ruckus, etc.) and reportedly some hosts will drop ARP requests or responses (gratuitous ARP) that exceed a certain threshold. This varies from 15 pps (Cisco, untrusted network) to 100 pps (Ruckus). Nmap on my network under some conditions sends over 500 probes in 3 to 6 seconds.
3. Some targets may only join the network intermittently when in low-power mode (iOS in particular, I notice). There is nothing Nmap can do to wake such a device via ARP scan, as far as I am aware.

This happens all the time to me with the -sn option. Tested with nmap versions from 7.80 (on various Raspberry Pi's) to the latest 7.93 (on Windows).

My use case:
Whenever I setup a new Espressif device flashed with Tasmota firmware, after it connects to my WLAN I have to find its IP to configure it. Using nmap with sudo for host discovery and searching for the vendor "Espressif" among the hosts will give me the IP, however I usually have to run the command inside a loop until I have a hit (sometimes it might discover the host at the first try, other times it might need 3 or 4 or even more tries, etc).

I see no difference between scanning the whole network like 192.168.1.* vs. performing a scan on a particular IP (both are unreliable and I need to scan multiple times to have a hit).

In my case I have noticed that I usually get a hit (i.e. that host is alive - in case it really is) after 4 tries. If ARP-ping sends 2 packets at most, I can be sure (but still not entirely) that the results are reliable only after having sent 8-10 packets, which is why I run this in a loop. So basically I agree with #2543, maybe it could be helpful to add an option for adjusting the number of packets sent?
Although this seems more like a workaround instead of a real fix, it should get the job done (most of the times).