nmap / nmap/nmap

Use system ARP cache to help with host discovery

Open
#2,499 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement Nmap
Dominant language
C
Stars
13.6k
Forks
2.9k
PR merge metrics
No merged PRs in 30d

Description

@dmiller-nmap and I were chatting about #92 and he suggested we might consider using a system's ARP cache to help with host discovery. This could help with devices that might ignore our probes because they already responded to another ARP request too recently (not sure how often this actually happens) or that our ARP scan might miss for other reasons. Or maybe it's over wifi or something and the system is just very briefly unavailable do to flaky network. On the other hand, could be a bit confusing that a system could show as "up" briefly due to caching even if it has been unplugged. User might even be scanning it to understand if/why it's not reachable. We might want to look into how long different systems keep ARP cache entries. We could note in the "reason" field why the host was marked up. And we could potentially have an option for avoiding this behavior. Or user could clear their ARP cache before scan if they wanted. Here's some notes from Dan:

One way would be to send the HostGroup through a function that updates the status and MAC address based on the cache before calling ultrascan. ultrascan would presumably not re-scan the ones that are already in a known state. That would probably be the easiest to implement. Another way would be to post-process it after ultrascan is done with discovery, filling in any that we missed. That would allow us to prefer the more up-to-date live result, but fall back on cache in case we missed something. The third approach would be to treat the arp cache as advisory only, and require some positive response to treat the target as up, which would probably mean a separate invocation of ultrascan discovery, probably using the default layer-3 discovery probes instead of ARP. for those "cached but not verified" targets.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review issue #92 and the HostGroup and ultrascan approaches described here before choosing an implementation path. Define how cached ARP entries affect host status and MAC data, how stale or unverified entries are handled, and whether users can identify or disable this behavior; the issue is done when those decisions and their behavior are implemented.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.