There’s a specific problem that regular ping can’t solve well: what happens when ICMP is blocked, but you still need to know if a host on your local segment is alive? That’s where arping comes in. It operates at the ARP layer instead of ICMP, which means it works even against hosts configured to silently drop ping requests, as long as you’re on the same local network segment.
I reach for arping constantly during local network assessments and troubleshooting, because ARP requests are handled by the network stack at a much lower level than most firewall software ever touches. A host can’t really refuse to answer ARP and still function on the network — it needs ARP to communicate at all.
How arping Works
arping sends an ARP request (or, in some modes, an ICMP-style ARP ping) directly to a target IP or MAC address and waits for an ARP reply. Since ARP operates purely within a local broadcast domain, arping only works for hosts on the same subnet/VLAN as the machine you’re running it from — it won’t cross routers the way ICMP ping does.
There are two well-known variants: the classic Linux iputils-arping (simpler, focused) and Thomas Habets’ arping (more feature-rich, supports both ARP “who-has” requests and reverse ARP lookups). Most Kali installs default to the Habets version.
Installation
Debian/Ubuntu/Kali:
sudo apt update
sudo apt install arping -y
RHEL/CentOS/Fedora:
sudo dnf install iputils -y
Verify:
arping --help
You should see usage output listing supported flags like -D, -U, -c, and -I.
Basic Syntax
arping [options] -I interface target_ip
Core Command Examples
Basic ARP ping to a host on the local network:
sudo arping -I eth0 192.168.1.1
Output:
ARPING 192.168.1.1
60 bytes from 00:1a:2b:3c:4d:5e (192.168.1.1): index=0 time=1.204 msec
60 bytes from 00:1a:2b:3c:4d:5e (192.168.1.1): index=1 time=0.912 msec
Limit to a specific number of requests:
sudo arping -I eth0 -c 4 192.168.1.1
Duplicate address detection mode (checks if an IP is already in use before you assign it):
sudo arping -D -I eth0 192.168.1.50
If the IP is free, arping reports no replies; if in use, you’ll see a reply with the owning MAC address.
Unsolicited ARP mode (announcing your own presence, useful after changing your IP):
sudo arping -U -I eth0 192.168.1.100
Quiet mode for scripting, only showing a summary:
sudo arping -f -I eth0 192.168.1.1
The -f flag exits as soon as the first reply is received, ideal for quick “is it alive” checks in scripts.
Configuration Options Worth Knowing
-I interface— mandatory in most setups to specify which NIC to send from, since ARP is interface-bound.-c count— number of ARP requests to send.-w timeout— how long to wait for replies before giving up.-D— duplicate address detection, extremely useful before manually assigning a static IP.-U— send unsolicited/gratuitous ARP, often used after IP reconfiguration or failover events.
Real-World Use Cases
1. Bypassing ICMP-blocking hosts during local recon. In an authorized internal assessment, if a host doesn’t respond to fping or ping sweeps, arping often reveals it’s actually alive, since ARP can’t be blocked without breaking basic connectivity.
2. IP conflict detection before deployment. Before assigning a static IP to a new server, I always run arping -D first to make sure nothing else on the segment is already using that address.
3. Detecting ARP spoofing or MITM setups. By tracking whether a given IP suddenly responds from an unexpected MAC address across repeated arping checks, you can spot signs of ARP cache poisoning during an incident response engagement.
4. Validating VLAN segmentation. Running arping from a host on VLAN A toward an IP believed to be on VLAN B should get no response if segmentation is correctly configured — a fast, low-noise sanity check.
Workflow and Tool Integration
A common pairing I use in local recon:
# Step 1: Broad discovery with arp-scan (or arping in a loop) across the subnet
for ip in 192.168.1.{1..254}; do
arping -c 1 -w 1 -I eth0 $ip 2>/dev/null | grep -q "Unicast reply" && echo "$ip is alive"
done
# Step 2: Feed alive hosts into Nmap for deeper service discovery
arping also complements tools like arp-scan and netdiscover — where those tools sweep a whole range automatically, arping is better suited for targeted, single-host ARP-layer checks or duplicate address detection.
Performance Optimization
- Since ARP requests are broadcast-based on a local segment, arping is inherently fast — there’s rarely a need to tune timing unless you’re scripting large loops.
- For scripted sweeps across a full /24, consider
arp-scaninstead, which is purpose-built for whole-subnet ARP sweeps and is considerably faster than looping arping manually.
Troubleshooting
- “Operation not permitted” errors almost always mean you forgot
sudo— raw ARP frames require elevated privileges. - No replies at all across every host usually means you specified the wrong interface with
-I, or you’re not actually on the same broadcast domain as your targets (e.g., testing across a VPN tunnel where ARP doesn’t traverse). - Duplicate address detection returning nothing doesn’t guarantee the IP is free — some devices are configured to not respond to ARP under specific conditions, so cross-check with a full port scan if it matters.
Common Mistakes
- Forgetting that arping only works within the same local broadcast domain — trying to arping a remote host across a router will simply fail or hit your default gateway’s MAC instead.
- Not specifying
-I, leading to arping picking an unintended interface on multi-homed machines. - Assuming a lack of ARP reply during a security assessment definitively means “host is down” — always cross-verify with another discovery method before concluding.
Best Practices
- Always specify the interface explicitly with
-Ito avoid ambiguity on multi-NIC systems. - Use
-Dbefore assigning any static IP in a production or lab environment to avoid conflicts. - When investigating suspected ARP spoofing, log MAC-to-IP mappings over time rather than relying on a single arping result.
Mini Lab Example
On an isolated VirtualBox host-only network with two VMs:
# From VM A, check if VM B is alive at the ARP layer
sudo arping -I eth1 -c 3 192.168.56.20
Expected output:
ARPING 192.168.56.20
60 bytes from 08:00:27:aa:bb:cc (192.168.56.20): index=0 time=0.812 msec
60 bytes from 08:00:27:aa:bb:cc (192.168.56.20): index=1 time=0.745 msec
60 bytes from 08:00:27:aa:bb:cc (192.168.56.20): index=2 time=0.699 msec
Then try blocking ICMP on VM B with a local firewall rule and re-run both ping and arping — you’ll see ping fail while arping still succeeds, which is the whole point of the exercise.
FAQ
Can arping work across the internet? No. ARP is a local-network-only protocol, so arping is limited to hosts within the same broadcast domain (typically the same VLAN/subnet).
Is arping detectable by IDS? Yes, ARP-based reconnaissance can be logged by network monitoring tools, especially if performed as a rapid sweep across many addresses.
What’s the difference between the two arping implementations? The iputils-arping version is simpler and ships with most Linux distros by default; the Thomas Habets version (common on Kali) has more flags, including duplicate address detection and unsolicited ARP modes.
Does arping need root privileges? Yes, sending raw ARP frames requires root or equivalent capabilities (CAP_NET_RAW).
Summary
arping fills a very specific but valuable niche: confirming host liveness at a layer that’s almost impossible to filter without breaking basic network function. Whether you’re doing local network reconnaissance during an authorized assessment, checking for IP conflicts before deployment, or investigating possible ARP spoofing, it’s a small tool that consistently earns its place in the toolkit.
References
- GitHub repository (Habets version): https://github.com/ThomasHabets/arping
- Man page:
man arping - iputils project (alternate implementation): https://github.com/iputils/iputils
