Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nmap's ARP scan misses alive hosts in some cases #92

Open
dmiller-nmap opened this issue Mar 26, 2015 · 9 comments
Open

Nmap's ARP scan misses alive hosts in some cases #92

dmiller-nmap opened this issue Mar 26, 2015 · 9 comments
Labels

Comments

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Mar 26, 2015

Need to figure out what is causing this and if there is any workaround. Most recent report: http://serverfault.com/questions/678324/one-device-shows-down-when-more-than-160-ip-addresses-are-scanned-with-nmap

@dmiller-nmap
Copy link
Author

@dmiller-nmap dmiller-nmap commented Dec 22, 2016

A few more mentions of this:

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?

@dmiller-nmap
Copy link
Author

@dmiller-nmap dmiller-nmap commented Jul 12, 2018

Did some research, so here are some links:

@Devenda
Copy link

@Devenda Devenda commented Jul 27, 2018

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

@pmorch
Copy link

@pmorch pmorch commented Aug 12, 2018

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.

@pmorch
Copy link

@pmorch pmorch commented Aug 14, 2018

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.

@cweiske
Copy link

@cweiske cweiske commented Mar 5, 2019

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
@TechnicalJohn
Copy link

@TechnicalJohn TechnicalJohn commented May 17, 2019

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

@Michaelpalacce
Copy link

@Michaelpalacce Michaelpalacce commented Jun 20, 2019

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

@pzoloprotonmail
Copy link

@pzoloprotonmail pzoloprotonmail commented Feb 6, 2020

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
nmap-bot pushed a commit that referenced this issue May 15, 2020
Two essential changes:

1. (ab)Use the ratelimit detection feature to hold off sending retransmissions,
preferring to send new ARP probes. Late responses will still be recorded, but no
longer counted as drops. This also gives each target the longest amount of time
to respond.

2. Send timing pings much more frequently. Since we're not sending any
retransmissions until timeout + ratelimit, we wouldn't otherwise have any data
on drops in order to speed up or slow down.

Results are faster ARP scans with fewer missed targets. See #92.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.