arp-scan, fping and masscan: Host Discovery Sweeps

"What is actually on this subnet?" sounds like the easiest question in networking and is routinely answered wrongly, because the tool you choose decides what you can see. Ping sweeps miss hosts that drop ICMP; port scanners miss hosts with no open ports; ARP scans cannot cross a router but see everything on the local segment, including devices with firewall rules that block everything else. This article compares arp-scan, fping, nmap and masscan on exactly that axis — what each one can and cannot see — with the commands worth memorising.

arp-scan: The Authoritative Layer-2 Sweep

ARP is not routable and it is not IP-filtered: every IPv4 host on the segment must answer an ARP request for its own address, including hosts with local firewalls. That makes arp-scan the most accurate inventory tool available on a local network, and also the one that shows you duplicate IP addresses, which nothing else will.

apt install arp-scan

arp-scan --localnet                       # sweep the interface's own subnet
arp-scan -I eth0 192.168.0.0/24           # explicit interface and range
arp-scan -I eth0 10.0.0.1-10.0.0.254      # ranges and CIDR both work
arp-scan -I eth0 --file targets.txt       # one target per line, "-" for stdin
arp-scan --localnet --limit 1             # exit early; useful in scripts
arp-scan -I eth0 -l -W /tmp/scan.pcap     # also save everything seen

# Who is answering as which vendor (first three octets of the MAC)
arp-scan --localnet | grep -v DUP
arp-scan --localnet -r 3 --retry 2        # more retries on lossy/wireless links

Reading the output is straightforward, but two entries deserve attention. (DUP: 2) means two devices claim the same IP — a genuine misconfiguration that produces intermittent and impossible-to-debug connectivity. Remember the ARP scan consumes one ARP request per target plus one retry, so it is gentle: a /24 is 256 packets, and even a /16 with --localnet is not a DoS risk.

Limits to be honest about: it works on IPv4 only (IPv6 uses NDP, which arp-scan does not implement), it needs raw socket privileges, and it stops at the first router. For a subnet behind a firewall you control, it is still the best inventory tool you have.

fping: Parallel ICMP with Scriptable Output

# /24 sweep, no DNS, only print the hosts that respond
fping -a -q -g 192.168.10.0/24

# Failures instead of successes
fping -u -q -g 192.168.10.0/24

# Fast sweep with explicit parameters, results to a log
fping -a -i 5 -r 1 -t 200 -p 10 -g 10.0.0.0/24 > alive.txt

# Continuous monitoring of a list
fping -f hosts.txt -l -p 1000

fping keeps a list of targets and can hold thousands of outstanding probes, which is why it outperforms a bash for loop with ping by orders of magnitude. It is the right tool for availability monitoring and for "is the whole rack up after the reboot" checks. It is the wrong tool for inventory: ICMP echo is often filtered on hosts, and even where it is not, you learn nothing about what the host is.

nmap: The Analyst's Tool

# Discovery only, no port scan
nmap -sn 192.168.10.0/24

# Ping the subnet with ARP on the local segment (needs root, most accurate)
nmap -PR -sn 192.168.10.0/24

# Fast top-100 port scan of live hosts
nmap -sT --top-ports 100 -T4 192.168.10.0/24 -oA scan_tcp

# Service and version detection on interesting hosts only
nmap -sV -p 22,80,443,161,3389 192.168.10.10-192.168.10.20

nmap's advantage is that it tells you what a host is: open ports, service versions, and often the OS. That also makes it loud and slow at scale — a /16 full-port scan takes hours and will light up every IDS you own.

masscan: Scale, Not Accuracy

# 10k packets/second across a large range - check with your network team first
masscan 10.0.0.0/16 -p443 --rate 10000 --output-format json -oJ https_scan.json

# Exclude ranges you must not touch
masscan 10.0.0.0/16 -p22,443 --rate 5000 --excludefile do-not-scan.txt

masscan can scan the entire IPv4 internet in minutes because it has its own TCP stack and never tracks connections. Consequences: it does not complete TCP handshakes, so results can be approximate; it will saturate a link if you do not set --rate; and on many networks it is indistinguishable from an attack. Run it only from a host and network you are authorised to blast, and always set a rate limit.

Choosing the Tool

Operational Hygiene

• Record the baseline. A weekly arp-scan saved to a versioned file turns "there is an unknown device" into a diffable event. This is one of the cheapest security controls available.
• Know your authorisation boundary. Scanning third-party address space is a legal event, not a technical one.
• Expect to be noticed. Announce scans to the security team; an unprepared SOC will treat a masscan run as a compromise and you will spend the day explaining it.
• Correlate with the switch. An ARP scan tells you a host exists; the MAC address table tells you which port it is on, which is what you need to find it physically — see our ARP spoofing detection notes for the defensive counterpart.

Related reading: nmap network discovery and port scanning, Dynamic ARP Inspection and Smokeping latency monitoring.

原文链接：https://man.archlinux.org/man/arp-scan.1.en