SubnetLayerProtocols

Ping, and the Difference Between Silence and Refusal

Why an explicit error is worth more than a timeout

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
IP has no way of telling anyone that something went wrong. A router that cannot deliver a packet just drops it, and the sender waits forever for a reply that will never come. That is unworkable, so ICMP was added alongside IP: a small protocol whose entire job is carrying bad news back to senders. 'Your packet's TTL ran out.' 'Nothing is listening on that port.' 'That packet was too big for the next link.' It also carries echo request and reply — the ping test — because a protocol for reporting problems is a natural place to put a mechanism for checking whether there are any.

✗ Common misunderstanding: If a server answers ping, its services are working.

Why that's wrong: Echo replies are generated by the IP stack with no application involvement. The web server can be stopped, crashed or listening on the wrong address and the ping still succeeds.

Correct model: Ping tests the stack and the path in both directions. Testing a service means connecting to that service.

The packets prove it: The ping trace completes without any application on the server being consulted — the reply is built by the stack from the request.

✗ Common misunderstanding: No ping reply means the host is down.

Why that's wrong: Filtering ICMP is routine hardening. A perfectly healthy host that has been told not to answer looks exactly like a dead one.

Correct model: Silence is the least informative outcome. An explicit error tells you far more than a timeout ever can.

The packets prove it: The filtered scenario shows echo requests arriving at a healthy server and nothing coming back — identical, from the sender's seat, to the host being switched off.

Watch these fields in the lab: icmp.type · icmp.code

Knocking on a building's front door to find out whether a particular office is open
somebody answering the door
→ an echo reply
learning nothing about the office you wanted
→ reachability without service
a building with a no-callers policy
→ a host or network that filters ICMP

Where it breaks down: A person at the door can be asked a follow-up question. Ping has exactly one question and one answer, and the reply carries no information about anything except that the stack responded.

  1. 1A reply. The host is reachable and its stack is working, in both directions. It says nothing whatsoever about any application on it.
  2. 2An explicit error. Something on the path is telling you exactly why delivery failed — and where, because the error's source address names the reporting device. This is the most useful outcome, and it is what filtering ICMP takes away from you.
  3. 3Silence. The least informative outcome. The request may have been lost, the reply may have been lost, or the host may simply have been told not to answer. You cannot distinguish these without another vantage point.

Watch these fields in the lab: icmp.type

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Which outcome tells you the most, and why?

Why must an ICMP error never be sent in response to another ICMP error?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.