Gyaan

Networking Tools and Troubleshooting

intermediate curl netstat tcpdump debugging

Knowing the right debugging tools is half the battle when something goes wrong in production. Let’s go through the most important networking tools and how to use them when things break.

curl — The Swiss Army Knife

curl is the most versatile HTTP tool. We use it to test APIs, check headers, debug requests, and more.

# Basic GET request
curl https://api.example.com/users

# Common flags
curl -v https://example.com           # verbose — shows headers, TLS handshake, everything
curl -I https://example.com           # HEAD request — just headers, no body
curl -o file.zip https://example.com/file.zip  # save output to file
curl -L https://example.com           # follow redirects (3xx)
curl -s https://example.com           # silent mode (no progress bar)

# POST with JSON body
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer token123" \
  -d '{"name": "Manish", "role": "admin"}'

# Check response time
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\n" \
  -o /dev/null -s https://example.com

Pro tip: -v (verbose) is our best friend when debugging. It shows the full request/response including TLS negotiation.

ping — Basic Connectivity Check

ping sends ICMP packets to check if a host is reachable and measure latency.

ping google.com              # continuous ping (Ctrl+C to stop)
ping -c 4 google.com         # send exactly 4 pings
ping -c 4 -W 2 10.0.0.5    # 2-second timeout per ping

If ping fails, it means either the host is down, there’s a network issue, or ICMP is blocked (many servers block ping for security).

traceroute — Map the Route

traceroute shows every hop (router) between us and the destination. Great for finding where packets get stuck.

traceroute google.com        # show all hops
traceroute -n google.com     # skip DNS lookups (faster)
# On some systems, use tracepath instead
tracepath google.com

If we see * * * at a specific hop, that router isn’t responding to our probes. If everything after a certain hop is * * *, that’s likely where the problem is.

ss / netstat — Check Open Ports and Connections

ss (socket statistics) replaced netstat on modern Linux. Same idea, faster output.

# List all listening TCP ports with process names
ss -tlnp

# List all listening UDP ports
ss -ulnp

# Show all established connections
ss -tnp

# Find what's using port 3000
ss -tlnp | grep 3000

# The older netstat equivalent (still works)
netstat -tlnp
netstat -anp | grep :80

The flags: -t = TCP, -u = UDP, -l = listening, -n = numeric (don’t resolve names), -p = show process.

nslookup / dig — DNS Debugging

When DNS seems wrong, these tools help us verify what’s actually resolving.

# Quick DNS lookup
nslookup pman47.cc
dig pman47.cc +short

# Check specific record types
dig pman47.cc MX +short
dig pman47.cc TXT +short

# Use a specific DNS server
dig @8.8.8.8 pman47.cc       # Google DNS
dig @1.1.1.1 pman47.cc       # Cloudflare DNS

# Full trace to see the resolution chain
dig pman47.cc +trace

tcpdump — Packet Capture

tcpdump captures raw network packets. It’s the nuclear option for debugging — we can see exactly what’s going over the wire.

# Capture all traffic on eth0
sudo tcpdump -i eth0

# Capture only HTTP traffic (port 80)
sudo tcpdump -i any port 80

# Capture traffic to/from a specific host
sudo tcpdump -i any host 10.0.0.5

# Save capture to a file (open in Wireshark later)
sudo tcpdump -i any -w capture.pcap

# Human-readable output with timestamps
sudo tcpdump -i any port 443 -A -tttt

tcpdump is powerful but noisy. Always filter by port or host to keep the output manageable.

iptables — Firewall Basics

iptables controls the Linux firewall. Most servers use it (or nftables/ufw which wrap it).

# List current rules
sudo iptables -L -n -v

# Allow incoming SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow incoming HTTP and HTTPS
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Block a specific IP
sudo iptables -A INPUT -s 203.0.113.50 -j DROP

# UFW is the friendlier alternative (Ubuntu)
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw enable
sudo ufw status

Debugging Workflow: “The Website Is Down”

When someone says the site is down, here’s a systematic approach:

  1. Can we reach it at all?

    ping myapp.com

  2. Is DNS resolving correctly?

    dig myapp.com +short

  3. Is the port open and the service listening?

    ss -tlnp | grep :80
curl -v http://myapp.com

  4. Is it a specific path or the whole site?

    curl -I https://myapp.com/
curl -I https://myapp.com/api/health

  5. Check the service logs

    journalctl -u nginx --since "10 min ago"
docker logs myapp --tail 50

  6. Check system resources

    top                  # CPU and memory
df -h                # disk space (full disk = silent death)
free -h              # memory

In simple language, debugging network issues is like following a trail. We start at the beginning (can we even reach the server?) and follow the path until we find where things break. These tools let us check every step along the way.

References