Ping

Ping Sweep: Finding Live Hosts With Bash and Nmap

Find every live host on a subnet with a bash one-liner, and when to reach for nmap -sn instead. Why a down result never means the address is free.
Ping sweep of a subnet with nmap -sn host discovery output
In: Ping, Nmap, Networking, Discovery

You need to know what is alive on a subnet: which IPs answer, which are free, whether that host you decommissioned is really gone. A ping sweep answers all three by pinging every address in a range and reporting who responds. You can do it with a five-line bash loop or a single nmap command, and knowing when to reach for which is the difference between a quick check and the right tool. This article shows both against a live lab subnet, and is part of the PingLabz ping guide.

What a Ping Sweep Actually Does

A ping sweep sends one ICMP echo request to each address in a range and records which ones reply. The result is a live-host inventory. Network engineers use it to find free addresses before assigning statics, to verify a VLAN's hosts after a change, and to confirm a migration moved everything it should have. (The same technique is step one of network reconnaissance, which is why you should only sweep networks you are authorized to touch; the offensive-security angle lives in the Nmap guide.)

The lab subnet here is 192.168.99.0/24, where only the router (192.168.99.1) and the test host (192.168.99.100) are up.

The Bash One-Liner

No tools to install, works on any Linux or macOS host, perfect for a quick check:

j@lab:~$ for i in 1 2 3 4 5 100 254; do
  ping -c 1 -W 1 192.168.99.$i >/dev/null 2>&1 \
    && echo "192.168.99.$i is up" \
    || echo "192.168.99.$i is down"
done
192.168.99.1 is up
192.168.99.2 is down
192.168.99.3 is down
192.168.99.4 is down
192.168.99.5 is down
192.168.99.100 is up
192.168.99.254 is down

The two flags doing the heavy lifting are -c 1 (one probe per host) and -W 1 (wait at most one second for the reply). Without -W, every dead host stalls for the full default timeout and a /24 sweep crawls. The && / || construction turns ping's exit code (0 = reply received, non-zero = no reply) into a readable up/down line.

To sweep a contiguous range, swap the explicit list for a C-style loop, and background the probes so they run in parallel instead of one-at-a-time:

j@lab:~$ for i in $(seq 1 254); do
  ping -c 1 -W 1 192.168.99.$i >/dev/null 2>&1 && echo "192.168.99.$i up" &
done; wait

The trailing & fires all 254 pings concurrently and wait blocks until they finish, taking the sweep from minutes to about a second. The tradeoff: output order is no longer sorted (pipe to sort -t. -k4 -n if you care).

The Catch: Sweeps Only See Hosts That Answer ICMP

This is the limitation that trips people up. A "down" result does not mean the address is free; it means nothing answered an ICMP echo within your timeout. Plenty of live hosts stay silent: Windows machines block ICMP by default in many firewall profiles, hardened Linux servers may drop echo, and any host behind a personal firewall can be up and serving traffic while ignoring your ping. A ping sweep reliably tells you what is there; it cannot prove what is not.

That gap is exactly why a dedicated scanner exists.

The Right Tool: nmap -sn

nmap -sn (the "no port scan" / host-discovery mode, formerly -sP) does a smarter sweep. On a local subnet it uses ARP, which is faster and cannot be firewalled by the host, and off-subnet it combines ICMP echo, an ICMP timestamp request, and TCP probes to ports 80 and 443, so it catches hosts that ignore plain ping:

j@lab:~$ nmap -sn 192.168.99.0/24
Starting Nmap 7.95 ( https://nmap.org ) at 2026-07-08 13:40 PDT
Nmap scan report for 192.168.99.1
Host is up (0.0027s latency).
Nmap scan report for 192.168.99.100
Host is up (0.00030s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 3.03 seconds

256 addresses in three seconds, using ARP on this local segment. Because ARP replies are mandatory for any host that wants to communicate on the LAN, an ARP-based sweep finds machines that a pure ICMP sweep would miss entirely. This is why, on your own local network, nmap -sn is strictly more reliable than a ping loop.

Choosing Between Them

Bash ping loop
Reach for it when: you're on a box with no nmap, need a fast yes/no on a handful of IPs, or want to script an up/down check into a health monitor.
Blind spot: misses any host that doesn't answer ICMP echo.
nmap -sn
Reach for it when: you need an accurate inventory, are on the local subnet (ARP), or the targets may be firewalled against ping.
Blind spot: needs to be installed; off-subnet it still depends on hosts answering something.

A useful rule of thumb: use the bash loop for a quick "is this one thing up?" and nmap for "what is the complete list of what's up?" When accuracy matters (auditing, migration verification, finding a rogue device), the ARP-backed nmap sweep is the answer.

A Middle Ground: fping

If nmap is unavailable but you want parallelism without wrestling bash job control, fping is purpose-built: fping -a -g 192.168.99.0/24 2>/dev/null pings the whole range in parallel and prints only the alive addresses (-a), one per line, ready to pipe into the next tool. It sits neatly between the loop and nmap.

Key Takeaways

  • A ping sweep inventories live hosts by pinging every address in a range. -c 1 -W 1 keeps a bash sweep fast.
  • Background the probes with & plus wait to sweep a /24 in about a second instead of minutes.
  • A "down" result only means "didn't answer ICMP." Firewalled-but-live hosts read as down.
  • nmap -sn uses ARP on the local subnet (unfirewallable) and multiple probe types off-subnet, so it finds hosts a ping loop misses.
  • Loop for a quick check, nmap for an accurate inventory, fping when you want parallel speed without nmap.
  • Only sweep networks you are authorized to scan.

This is the last stop in the cluster. Head back to the complete ping guide, or go deeper on scanning in the Nmap guide. This is a network administration technique; use it only on systems you own or are authorized to test.

Written by
More from Ping Labz
Ping MTU test with the DF bit hitting a 1400-byte link
Ping

Testing MTU With Ping and the DF Bit

Find the path MTU with nothing but ping, from Linux and IOS XE, against a real 1400-byte link. The 28-byte math and the PMTUD black holes that hang TCP.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.