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.
