From Wire to DNS: A Structured Diagnostic Flow (v3)

A layered methodology for diagnosing Linux network issues by isolating failures from physical connectivity through upstream path analysis and name resolution. This is a systems model — not a reaction guide.

Architecture Series Evidence Over Emotion mtr + ping Router ICMP Trap Included

1. Core Principle

Network problems are rarely “the internet.” They are almost always a failure at a specific layer. Stability comes from structured isolation and repeatable tests.

2. The Layer Model

Physical — Cable, RF signal, NIC hardware
Link — Speed, duplex, association, MAC learning
Local IP — Gateway reachability
Upstream Path — ISP routing & transit
DNS — Name resolution services
Application — Browser, SSH, API client

Diagnose in order. Never skip layers.

3. Isolation Strategy

Change one variable at a time (wired vs Wi‑Fi is the most decisive)
Compare two devices on the same network (symptom correlation)
Separate raw IP reachability from DNS resolution
Prefer tests that terminate and produce comparable snapshots

4. Instrumentation by Layer

Physical / Link

ethtool eth0
iw dev wlan0 link

Local IP

ping -c 50 192.168.1.1

Upstream Path Analysis (mtr)

# Snapshot report (preferred for logging / watch)
mtr -rwzbc 100 1.1.1.1

# Live monitor (run directly, not inside watch)
mtr -ezbw 1.1.1.1

DNS

getent hosts google.com
ping -c 5 google.com

Truth Observation

tcpdump -e -i eth0

5. Interpreting mtr (What Matters)

Loss at the final hop is meaningful end‑to‑end loss
Loss at an intermediate hop is often ICMP rate limiting
Latency spikes on a hop that do not propagate are often diagnostic noise

Rule: Intermediate hop “loss” is only real if it continues all the way to the destination.

6. The mtr Hop‑1 Trap (Router ICMP Rate Limiting)

Consumer routers often deprioritize or rate-limit ICMP replies (especially under load). This can make mtr show dramatic loss at hop 1 (your gateway) even while your real traffic is forwarded normally.

If hop 1 shows high loss but hops 2..N and the destination show 0% loss → the router is ignoring probes, not dropping traffic.
Validate gateway health with a direct ping test.

# Gateway validation (gentle but meaningful)
ping -c 200 -i 0.2 192.168.1.1

Example outcome: 200 transmitted / 200 received / 0% loss → LAN is healthy. mtr hop‑1 “loss” was a diagnostic artifact.

7. Router & Infrastructure Checks

Reboot modem first, router second (order matters)
Inspect router logs for WAN drops, restarts, DHCP storms
Wi‑Fi: use stable channels (2.4GHz: 1/6/11; avoid DFS surprises on 5GHz if you see hopping)
Consider powerline Ethernet if cabling is not an option

8. A Practical Monitoring Script (The “bash’edness” pattern)

This is a lightweight harness you can run under watch. It locates mtr and runs a single monitoring command. Prefer the -r report form if you want stable snapshots.

#!/usr/bin/env bash

### Universal SHMOD
###  Run it like this:
### /usr/bin/watch -n 180 -t /usr/local/bin/mtr--monitor.sh

## Find mtr location on any distro
MTR="$(/usr/bin/which  mtr)"

if [ -z "$MTR" ]; then
    /usr/bin/echo "mtr not found. Exiting."
    exit 1
fi

/usr/bin/echo "=== $(/usr/bin/date '+%F %T %z') ==="
/usr/bin/echo "${MTR} -rwzbc 100 1.1.1.1"
"${MTR}" -rwzbc 100 1.1.1.1

/usr/bin/echo
/usr/bin/echo "========================================"

Under watch, use report mode (-r) so each run terminates cleanly. Use -ezbw only when running mtr directly (interactive/live view).

9. Architectural Philosophy

Never debug “the internet.” Debug the layer.

Tools serve the model — not the other way around. When diagnostics conflict, trust end-to-end results (destination loss/latency) and validate locally with controlled tests.