First of all, I don't think Nmap is showing "wrong" results to you. You are getting different results as expected, because you are doing different scans, even if you don't know that. Using Nmap is not like using a magic option combination that will give you straight away a definitive result. There exist different techniques because different devices in the network behave differently (routers, firewalls, different OS...), and also you might want to be more or less "invisible". Herein, the beauty of Nmap is its flexibility, that allows you to conduct many different scans to find what you need. Imagine it as a mapping tool that will give you X results with some options and Z results with some others. Then, it is your brain who should interpret them and come to conclusions. You only ran the basic command with all the default options, and there is much more to explore.
[1] You are doing only a ping scan, which by default will do the following:
- Send an
ICMP
echo request
- Send a
TCP ACK
packet to port 80
NOTE: Newer Nmap versions (I believe yours included) also send a TCP SYN
packet to port 443
and an ICMP
timestamp request.
[2] If you are in the same network (and you are a super user), which in your case means the computer running Nmap has an IP like 192.168.1.X
, an ARP
request will be used instead. If you use Wireshark
you can see the ARP
packet exchanges.
[3] Lastly, the default behaviour of [1] uses RAW packets for the ICMP
echo and the TCP ACK
, so when you use an unprivileged user then Nmap cannot use this technique. Instead, Nmap will send a TCP SYN
packet to port 80
, by using connect as your normal user applications will do.
If you understand how Nmap is working ([1], [2] and [3]) then you can see why you are getting different results.
In your first scan, both computers (192.168.1.1
and 192.168.1.4
) accepted the TCP
connection. This used to be a very noisy scan, because applications will log the fact that you have accessed them. But you got what you wanted: seeing they were alive. Note that you can configure this type of scan when running Nmap as a super user (so even when you are a super user you can use [3] instead of [1] or [2]) and you will have obtained exactly the same result.
Your second scan sent an ACK
to port 80
and an ICMP
echo, and 192.168.1.1
ignored it. This could mean that it has a firewall in place. On the other hand, 192.168.1.4
responded either to the ACK
or the ICMP
echo. If you were in the same network (192.168.1.0
), then ARP
would have been used instead (see [2])... but if that was the case, for some reason 192.168.1.1
would have not responded to your ARP
request, which I find unusual. Therefore, I would guess that you were not in the same network.
In your third scan, in my opinion 192.168.1.3
should have given you the same results as it did in the second scan. The fact that 192.168.1.3
did not show up in the second scan might respond to different facts - perhaps it was connected through wifi and it was down? It happens to my phone sometimes when it disconnects automatically to save power. Did you get these results consistently? You should run more verbose scans to see why exactly Nmap is interpreting network hints the way it does.
Finally, if you are serious about learning the tool, I strongly recommend you to get Fyodor's Nmap book. It is great not only to understand how Nmap works, but also some computer networks behaviour and other tricks. For example, you could use -n
to skip reverse DNS
lookups and speed up your test. You could also try different ping ports (from the default 80
) and different types of ping.