ToolkitReconnaissance

Practical documentation · Authorized use only

arp-scan

arp-scan performs fast, explicit ARP discovery on a directly connected IPv4 segment. It is ideal for a repeatable local asset inventory and for spotting unmanaged devices that conventional IP discovery misses.

ARPNetworkCLIReconnaissanceAsset Management

Start safely and get useful results

Best for

  • • Local IPv4 asset inventory
  • • CMDB reconciliation

Not for

  • • Routed networks
  • • Attributing devices from MAC vendors alone

Before you run anything

  • • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
  • • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Discover devices on the active local interface

Scenario: Build a controlled baseline of an approved office test VLAN.

sudo arp-scan --localnet --interface=eth0

Probe the IPv4 subnet configured on eth0; replace it with the approved interface.

Expected use: Each response shows IP, MAC, and a best-effort vendor lookup.

Intermediate

Capture an auditable baseline

Scenario: Compare two approved discovery runs after an asset-change window.

sudo arp-scan --localnet --interface=eth0 --plain | tee arp-scan-$(date +%F).txt

Emit compact output and retain a timestamped evidence file.

Expected use: Diff the output with a known-good baseline; account for DHCP churn before escalating.

Interpret results like an analyst

  • • A missing response can result from host firewalling, sleep state, VLAN isolation, or a different L2 segment.
  • • Prioritize unknown devices by asset owner and switch-port evidence rather than MAC vendor labels.

Common mistakes and operating tips

Avoid

  • • Scanning an interface that is not on the intended VLAN.
  • • Assuming --localnet can discover hosts beyond the local broadcast domain.

Operational discipline

  • • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
  • • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation