Skip to content

ping

The ICMP article on ping already covered what happens on the wire — an Echo Request out, an Echo Reply back, and how to read RTT, TTL, and mdev from the result. This article stays at a different level: ping as a command you actually type, and the fact that it's not quite the same command depending on which operating system you're sitting at.

The default behavior differs by OS, and that trips people up

Run ping example.com with no flags on three different machines and you get three different behaviors:

  • Linux sends Echo Requests once per second, forever, until you press Ctrl+C.
  • Windows sends exactly four and stops on its own.
  • macOS, like Linux, keeps going until interrupted.
ping example.com

Pinging example.com [93.184.216.34] with 32 bytes of data:
Reply from 93.184.216.34: bytes=32 time=101ms TTL=124
Reply from 93.184.216.34: bytes=32 time=100ms TTL=124
Reply from 93.184.216.34: bytes=32 time=120ms TTL=124
Reply from 93.184.216.34: bytes=32 time=120ms TTL=124

Ping statistics for 93.184.216.34:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 100ms, Maximum = 120ms, Average = 110ms

Windows' default 32-byte payload is also smaller than Linux's default 56 bytes, and Windows reports round-trip time in whole milliseconds rather than the fractional precision Linux shows. None of this changes what ping is measuring — it's the same Echo Request/Reply exchange everywhere — but a script or a habit built around one OS's output format won't parse cleanly against the other, and "why did Windows only send four and stop" is a question that trips up a lot of people used to Linux's continuous default.

Linux Windows
Default count Continuous (Ctrl+C to stop) 4
Default payload 56 bytes 32 bytes
Set count explicitly -c N /n N
Set TTL -t N /i N
Set Don't Fragment -M do /f

Using ping for path MTU discovery

Beyond a basic reachability check, ping doubles as a quick way to find the largest packet size a path can carry without fragmentation — useful when a VPN tunnel or an unusual link somewhere in the path has a smaller MTU than the default 1500 bytes assumed everywhere else. Sending a payload with the Don't Fragment bit set, and reducing the size until it stops failing, brackets the actual path MTU directly:

ping -M do -s 1472 -c 2 example.com

PING example.com (93.184.216.34) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1442

-s 1472 requests a 1472-byte ICMP payload, which together with the 8-byte ICMP header and 20-byte IP header adds up to exactly 1500 bytes — the standard Ethernet MTU. The local error: message too long, mtu=1442 response means something in the path — commonly a VPN adding its own encapsulation overhead — has a smaller MTU than that, and 1442 is what this particular link can actually carry. Repeating the test with -s reduced by the overhead reported brackets the true path MTU without guessing. This is the same MTU concept the TCP deep dive module covers in the context of segmentation — here it's ping doing the measuring instead of a TCP handshake negotiating MSS.

Note

On Windows, the equivalent flags are /f (Don't Fragment) combined with /l <size> for payload length — the same idea, different syntax.

Practice exercises

  1. On a Linux machine, run ping -c 4 <a nearby server> and ping -c 4 <a distant one>, and compare the reported payload size in the first line of output against what a Windows machine would show by default for the same command.
  2. Using the MTU discovery technique above, find the largest ICMP payload your own internet connection can send without fragmentation to a public host, starting from 1472 and adjusting downward.
  3. A teammate on Windows reports "ping only sent four packets and stopped, is something wrong?" — explain why that's expected, and what flag makes it behave like the Linux default.

ping confirms a destination answers and roughly how fast. It says nothing about what's actually running on that destination, or which of its ports anyone can even reach — a separate, and in practice much more common, kind of question this module turns to next.

Sources