2

I am scanning my network to find out IP Addresses by using these two commands.

arp -a

nmap -sn 192.168.1.0/24

For some reason, my Smart Plug (and some other android devices) only show up in the scan done with arp -a. Does anyone know the reason?

2

arp -a prints a cached list of hosts/devices that have been talking to this host. Therefore if you see your smart plug and other devices appearing in the output, it's proof they were talking to this host since the last reboot of the Pi or restart of its' networking.

In a nutshell:

Your nmap is doing OUTWARD scanning of the specified subnet from the Pi doing it.

Your arp output is a list of IP:mac address mappings of hosts that your pi has exchanged traffic with.

So the nmap scan can show many hosts, whereas the arp cache tells you only hosts your Pi has been talking to

The arp cache of a Pi at 192.168.1.21 is shown below:

arp -av
gateway (192.168.1.18) at d4:ca:6d:XX:XX:5e [ether] on eth0
gateway (192.168.3.126) at d6:ca:6d:XX:XX:26 [ether] on wlan0
pi3Bplus-2 (192.168.1.22) at b8:27:eb:XX:XX:3c [ether] on eth0

The arp output will shows ip:mac address mappings for (2) types of hosts:

A) hosts ("ie pi3Bplus-2") within the same subnet as your pi which can directly exchange traffic and

B) Routers ("ie gateway") required to route traffic to hosts outside your host's subnet.

Remark that 192.168.1.22 is in 192.168.1.21's cache: That's because I pinged .22 from .21. So an entry in the arp cache is proof of correct connectivity between hosts when troubleshooting. Of course if ICMP were blocked in a firewall, the ping would fail and the host's IP:mac mapping would not be present in the arp cache.

Also note that the arp cache is NOT persistent! if you restart the Pi or even the networking, it will blow-away the arp cache. Which you might actually want to do when testing.

  • There are some things in your answer that may be confusing. Quote: "it's proof they were talking to this host since the last reboot of the Pi or restart of its' networking." - No, the ip address is removed from the cache after 5 minutes if there wasn't a (new, continued, etc.) connection before. If you continue a connection after 10 min then there is a new arp request. Even though the remote device is active you will not find it in the cache for 5 min. – Ingo Jun 10 at 9:04
  • Quote: "So an entry in the arp cache is proof of correct connectivity between hosts" - No, if you shut down the remote device and you look at the arp cache within 5 min you will find its ip address. This all may confusing troubleshooting because things may work but a short time later it doesn't, in particular if arp request in one direction doesn't work correct. – Ingo Jun 10 at 9:10
  • @Ingo arp aging should work like that, but my experience is that garbage collection doesn't purge stale entries according to the defined period. Tests in my answer were done using 2 Pi's addressed on same subnet (connected to same switch) pinging each other a few times & halting their pings. If you repeat this test and run ip -statistics neighbour periodically you'll see arp entries marked "stale" remain even if older than 20 min! So I get your point about how arp aging is supposed to work, but repeat the and you'll see entries can live way beyond 5 min. Excellent point however!!! – F1Linux Jun 10 at 10:36
  • I just have made different experiences ;) On working with proxy arp I stumbled about a situation where arp request only works in one direction, from the remote device to the RasPi. The connection only worked when the remote device connected to the RasPi - for 5 min. The other way around it sometimes worked (within 5 min after connect from remote) and sometimes it doesn't. It was very difficult do find this intermitted error (solved it with promiscuous mode). – Ingo Jun 10 at 11:16
  • Anyway - what our discussion shows and what I believe: asking the arp cache for ip addresses is not a save solution, unless you ping the broadcast address before looking at the arp cache. But that's a possibility I will not suggest because of network load. – Ingo Jun 10 at 11:21
1

This is not really a question specific to Raspberry Pi. Anyway, I will give a detailed answer because finding the ip address of a Raspberry Pi is a very often asked question and problem here.

nmap is a network scanner and it does what you expect: it actively scans the network for devices.

The command arp (you should better use ip neighbor) is not a scanner. It only shows the content of the local arp cache.

To establish ethernet connections, the arp protocol is used. It asks what ethernet devices with mac address have what ip address. The found mapping of mac address to ip address are stored in the local arp cache, by default for 5 minutes. This mapping takes place for every established connection, even when the remote device does not response to ping queries. But this also implies that you do not find a device in the arp cache if there wasn't made a connection the last 5 minutes before.

Your command nmap -sn 192.168.1.0/24 only do a simple ping scan with disabled port scan. This will not find devices that suppress ping replies. This may result in that you find ip addresses in the arp cache but don't find it with active ping scan. You may try to use:

rpi ~$ nmap -Pn 192.168.1.0/24

This will scan the first 1000 ports on all 255 ip addresses on the network. Of course this will take a very long time. You may consider to use only one port to scan or use other options for nmap to find your devices.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.