2

Here is what I do and what happens :

  • Let assume I have a device A with IP X.X.X.200 connected to the network
  • I use Nmap to ping my local network, with the command "nmap --send-ip -sP 192.168.1.1/24"
  • Look at the arp table using "arp -a", the device A is displayed with his MAC, no problem
  • Now I change manually the IP for A, I set the static IP to X.X.X.201
  • I use the same Nmap command "nmap --send-ip -sP 192.168.1.1/24"
  • Look at the arp table with "arp -a", and then A appears 2 times. One for IP X.X.X.200 and one for IP X.X.X.201

So the Nmap command did not refresh the IP X.X.X.200, that means it does not really ping all IPs. Because if I ping manually X.X.X.200, then it would get no response and disappear from the arp table.

So I would like to know how to use this tool, to really refresh an re-populate the arp table.

Thank you.

  • 1
    What happens is desirable. It would not be desirable for an interface with multiple IP addresses to have the ARP cache changed every time one of the different addresses is used. The ARP cache will naturally timeout MAC addresses. You can probably clear the ARP cache, and it will get rebuilt naturally. – Ron Maupin Aug 6 '15 at 1:24
  • @Ron - Please post this as an answer as you are spot on! – Benjamin Dale Aug 6 '15 at 1:25
  • @Benjamin Dale, it's done. – Ron Maupin Aug 6 '15 at 1:28
6

What happens is desirable. It would not be desirable for an interface with multiple IP addresses to have the ARP cache changed every time one of the different addresses is used. The ARP cache will naturally timeout MAC addresses. You can probably clear the ARP cache, and it will get rebuilt naturally.

  • Thanks Ron, it makes sense when thinking about multi IP machines. So I believe there is nothing to do to change this behavior. Deleting the table seems to be a good idea. – phenetas Aug 6 '15 at 21:39
2

Further to Ron's answer - you are confusing your Protocol Layers - NMAP (and ping and other applications) do not populate the ARP cache - your system OS does this via your IP stack.

The ARP cache does not indicate the liveness of a MAC to IP mapping, it merely tells the host that at some point within the last $arp_cache_timeout seconds, this MAC responded to an ARP request for this IP.

In your example case when nmap tries to connect to x.x.x.200, the IP stack in your OS sees that there is an entry already in the ARP cache, and simply builds an Ethernet frame destined for the cached MAC Address (which happens to be your local MAC) and sends it. The lack of response received is because your IP stack no longer responds on that IP address.

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.