ping Command on Mac: -t, -n and -W Mean Something Else

I typed a Linux habit into the Mac mini that runs this business: ping -c 3 -W 1 1.1.1.1. No reply lines came back. The summary said 3 packets transmitted, 3 packets received, followed by 3 packets out of wait time, and the exit code was 0. On Linux, -W 1 means "wait one second for a reply". On macOS it means one millisecond, so every reply arrived "late", got counted, and was never printed. A script that greps for bytes from would call the host down while the exit code says it's up.

That's one of several flags the ping command on Mac reads differently from Windows and Linux. I ran about 60 ping invocations on macOS 26.4.1 without sudo, recorded the exit code and wall time of each, read the matching lines in Apple's published ping.c, and sorted all 121 Ask Different questions with "ping" in the title. This post continues the networking series that started with traceroute on Mac and nslookup on Mac.

The ping commands I'd actually use on a Mac

# five pings, then a summary (without -c it runs until Ctrl-C)
ping -c 5 192.168.20.1

# give up after 3 seconds total, whatever happens
ping -t 3 example.com

# per-reply timeout is in MILLISECONDS on macOS
ping -c 3 -W 1000 example.com

# stop at the first reply (good for "is it back yet?")
ping -o -t 60 192.168.20.1

# IPv6 needs the separate binary
ping6 -c 3 ::1

# largest packet that fits a 1500-byte MTU without fragmenting
ping -c 1 -D -s 1472 192.168.20.1

Everything above works as a normal user. /sbin/ping on this machine is r-xr-xr-x root wheel, with no setuid bit, because for a non-root user it opens an unprivileged ICMP datagram socket (ping.c line 315) instead of a raw one.

Flags that mean something else on macOS

Each row in this table is a command I ran against my router or 1.1.1.1. The Windows and Linux columns come from Microsoft's ping reference and the iputils man page.

Flag	Windows	Linux (iputils)	macOS	What happened here
(none)	4 pings	until Ctrl-C	until Ctrl-C	SIGINT after 4.5 s: 5 sent, exit 0
-t	ping until stopped	IP TTL	total deadline, seconds	ping -t 1.1.1.1: usage, exit 64
-n 4	count	numeric output	numeric output	usage, exit 64
-W 1	(no such flag)	reply wait, seconds	reply wait, milliseconds	replies hidden, exit 0
-w 5	reply wait, ms	deadline, seconds	not an option	exit 64
-4 / -6	pick IP version	pick IP version	not an option	exit 64

The -t row confuses people in a quiet way. One Ask Different question came from someone with the Windows -w habit who concluded that ping -t 5 on Mac sets the packet count, because it produced five replies. It's a five-second deadline; at the default one-second interval that happens to be five packets. My ping -t 3 1.1.1.1 sent three. And ping6 uses -t for a third thing, a Node Information query that takes no argument, so ping6 -t 5 ::1 tried to resolve "5" and exited 1.

Why -W 1 hides the replies but still exits 0

The man page says it in one sentence ("If a reply arrives later, the packet is not printed as replied, but considered as replied when calculating statistics"), and the source shows the order of operations. In line 1348, a reply slower than the wait time increments a counter and returns before the print statement. The received count was already incremented a few lines earlier. The exit code depends only on that count: 0 if anything came back, 2 if nothing did (line 1639). Even -W 0 gave me one silent reply and exit 0. If you port a Linux script, multiply its -W value by 1000, or check the exit code instead of the output.

How long ping takes to give up on a dead host

I pinged an unused address on my LAN, 192.168.20.250, with different flags and timed each run:

The 11 seconds for a single ping is one second of interval plus a 10,000 ms wait after the last packet when nothing has been received (line 1086; when replies did arrive, it waits twice the slowest round trip instead). The second bar is the odd one. With -D -s 1473 the packet is too big to leave the Mac at all, ping prints sendto: Message too long, and then still waits the full 11 seconds for a reply to a packet it never sent. A send error is a warning in this code, not an exit. If a script needs a bound on the time, use -t, which caps the whole run.

ping exit codes on Mac

Exit	Meaning	What produced it here
0	at least one reply	router, 1.1.1.1, also the hidden -W 1 replies
2	sent, nothing back	dead host; TTL exceeded with -m 1; any sendto error
64	usage error	-n 4, bare -t, -w, -4, -c 0, -s 65508
68	name didn't resolve	nosuchhost.invalid, a MAC address, ::1
77	needs root	-f, -l 3, -i 0.001
1	other errors	-b utun99 (bad interface name)

Two things in that table surprised me. The interval limit for normal users is 2 ms, not one second: -i 0.002 sent three pings in 0.03 seconds without sudo, and only -i 0.001 was refused (line 432). And a TTL-exceeded reply from my router counts as no reply, exit 2, even though something did answer.

ping ::1 says Unknown host

ping -c 1 ::1 printed ping: cannot resolve ::1: Unknown host and exited 68, the same code as a misspelled hostname. A link-local address with a scope, fe80::1%en1, failed the same way. The address is valid; macOS ping only asks the resolver for IPv4 (gethostbyname2(target, AF_INET), line 687), so an IPv6 literal can never resolve. ping6 -c 1 ::1 worked. ping google.com picked an IPv4 address, and ping6 google.com failed with UDP connect: No route to host, because this network has no IPv6 route. The asker in this IPv6-only server question got the same two messages, Unknown host from ping and No route to host from ping6. The second one is about the route, not about ICMP being blocked.

Packet size: 1472 for the MTU test, 8184 without root

ping -c 1 -D -s 1472 192.168.20.1 came back as 1480 bytes; with -s 1473 and the don't-fragment flag, it failed locally with Message too long. Without -D, 1473 went through. So the Wi-Fi link has a 1500-byte MTU (1472 + 8 ICMP + 20 IP). One unanswered Ask Different report says that on Sequoia with SIP enabled, the DF bit doesn't appear on the wire. I didn't capture packets for this post (that needs sudo, see tcpdump on Mac), so I can only say -D changed what happened locally.

Larger sizes have a ceiling that ping doesn't tell you about. -s 8184 worked and -s 8185 failed with sendto: Message too long. sysctl net.inet.raw.maxdgram is 8192 here, which is 8184 bytes of data plus the 8-byte ICMP header. ping's own size check allows up to 65507, so anything from 8185 to 65507 passes the parser, fails at send time, and waits the 11 seconds from the chart. 65508 gets a proper error, exit 64.

What 121 Ask Different questions about ping are about

I pulled every question on apple.stackexchange.com with "ping" in the title through the Stack Exchange API (121 unique) and sorted them by title:

Topic	Questions	Total views
ping and dig/nslookup/hosts disagree about a name	27	160,580
latency spikes, mostly on Wi-Fi	24	87,648
can't reach another machine, or the Mac doesn't answer	16	81,381
scripting: timeouts, rate, parsing output	12	69,035
ping works but web or apps don't	11	19,905
binary, privileges, "killed", DF bit	10	12,003
can't ping localhost or its own address	7	104,487
other (IPv6 3, monitoring apps 3, LAN sweeps 2, off-topic 6)	14	95,073

The biggest group is about names, not ICMP. ping goes through the system resolver, which reads /etc/hosts, mDNS and per-domain resolver settings, while dig and nslookup query a DNS server directly, so the two can give different answers for the same name. I measured that split for five tools in the nslookup post. In the binary group, one question shows ping getting killed on an M1 Mac while /sbin/ping worked; the asker's PATH put Homebrew's inetutils ping first (question 449481). which -a ping shows which one you're running, and zsh: killed on Mac covers that error. On the latency side, my own baseline over Wi-Fi was 150 pings at 0.2-second intervals to the router: median 3.3 ms, 99th percentile 11.1 ms, one outlier at 46.4 ms, no loss.

The autocomplete data shows another use: "ping mac address to get ip". You can't. ping takes an IPv4 name or address, and ping c6:47:8f:00:00:01 exited 68 like any unresolvable name. The MAC-to-IP table lives in the ARP cache, which the arp command on Mac post reads.

A function that waits until a host answers

# waitup HOST [SECONDS] -- block until HOST answers one ping, or give up.
# exit 0 = answered, 2 = no reply within SECONDS, 68 = name did not resolve (IPv4)
waitup() {
  local host=$1 secs=${2:-60}
  if [[ $host == *:* ]]; then
    # ping6 has no deadline flag (-t means something else), so loop it
    local end=$(( SECONDS + secs ))
    while (( SECONDS < end )); do
      ping6 -c 1 -q "$host" >/dev/null 2>&1 && return 0
      sleep 1
    done
    return 2
  fi
  ping -o -q -t "$secs" "$host" >/dev/null 2>&1
}

-o exits on the first reply and -t caps the wait, so one ping invocation covers the IPv4 case and the exit code carries the answer. I tested five cases: my router returned 0 immediately, the unused address returned 2 after 3 seconds, nosuchhost.invalid returned 68 at once, and ::1 and localhost returned 0. The IPv6 branch can overrun the limit, because each ping6 -c 1 to a silent host waits on its own; I only tested it against ::1. It's the check I'd put in front of an SSH retry after a restart.

FAQ

How do I use the ping command on Mac?

Open Terminal and run ping -c 5 followed by a hostname or IPv4 address, for example ping -c 5 example.com. Without -c, macOS ping keeps going until you press Control-C, then prints a summary. Use -t for a total time limit in seconds and -W for the per-reply wait in milliseconds. IPv6 addresses need ping6.

What is the Mac equivalent of ping -t on Windows?

Plain ping with no options. On macOS it already runs until you press Control-C. Typing ping -t host on a Mac fails with a usage error (exit 64), because -t on macOS takes a number: the total number of seconds before ping exits.

Why does ping say Unknown host for an IPv6 address on Mac?

macOS ping only handles IPv4. It asks the resolver for an IPv4 address only, so an IPv6 address such as ::1 is reported as "cannot resolve ::1: Unknown host" with exit code 68. Use ping6 instead, for example ping6 -c 3 ::1.

Method: every command ran on 2026-10-07 between 12:05 and 12:15 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253) on Wi-Fi (en1), as a normal user without sudo, using /sbin/ping and /sbin/ping6. Times are wall-clock for single runs. Source references are to ping.c at the network_cmds-741.100.2 tag of Apple's open-source repository; I didn't confirm that tag matches the shipped binary byte for byte, but every behavior cited above matched what the binary did. The question counts come from the Stack Exchange API (search on title "ping", 122 results with one duplicate), sorted by title only, not by reading each answer. Not tested: flood and preload as root, packet capture of the DF bit, broadcast or subnet sweeps, and changes to the firewall's stealth mode (it's off on this machine).