Network Troubleshooting for Beginners: Part 5 — tcpdump, sngrep and Wireshark

Sometimes all checks pass: ping responds, DNS works, ports are open, mtr shows no loss, but the application still receives errors like connection reset by peer or TLS handshake failed. In those cases you need to look at the packets themselves — capture the traffic and dissect what happens in the connection. This part covers three tools: tcpdump for capture, sngrep for SIP and Wireshark for analysis.

tcpdump: capturing packets

tcpdump is available in almost every Linux distribution. It shows packets in the console and can save them to a pcap file for later analysis.

List of interfaces available for capture:

sudo tcpdump -D

Traffic to/from a specific host:

sudo tcpdump -ni eth0 host 203.0.113.10

The -n flag disables translating addresses and ports to names: output is faster and does not generate DNS queries from tcpdump itself.

Only HTTPS:

sudo tcpdump -ni eth0 tcp port 443

Only DNS queries and responses:

sudo tcpdump -ni eth0 port 53

Save traffic to a file for Wireshark:

sudo tcpdump -ni eth0 -w /tmp/capture.pcap

Limit the size so you don’t fill the disk:

# stop after 1000 packets
sudo tcpdump -ni eth0 -c 1000 -w /tmp/capture.pcap

# start a new file every 60 seconds; filename is specified by a strftime template
sudo tcpdump -ni eth0 -G 60 -w '/tmp/capture-%Y-%m-%d_%H-%M-%S.pcap'

The default snap length (captured portion of the packet) is 262,144 bytes, so packets are saved in full. The -s 0 parameter in older instructions was needed for versions with a smaller default; in modern versions it means the same default value.

tcpdump filters (host, port, tcp, udp and their combinations via and, or, not) are capture filters: packets that don’t match them do not get into the file at all.

sngrep: SIP dialogs in the terminal

sngrep is designed for telephony debugging: it collects SIP packets into calls and displays them as dialogs — REGISTER, INVITE, responses like 100 Trying, 180 Ringing, 200 OK, and so on. This is more convenient than parsing SIP in tcpdump output.

sudo apt install sngrep
sudo sngrep                 # live capture
sudo sngrep port 5060       # only SIP on the standard port
sngrep -I /tmp/capture.pcap # open a saved file

In the interface, use the arrow keys to select a call; Enter opens the message exchange view.

Wireshark: analyzing a capture

Wireshark is a graphical packet analyzer. A convenient workflow with a server is: capture traffic with tcpdump on the server, download the file and open it in Wireshark on your workstation.

scp user@server:/tmp/capture.pcap .
wireshark capture.pcap

Display filters are set in the filter bar above the packet list:

• http.request — only HTTP requests;
• tls.handshake — TLS handshake messages;
• dns — DNS queries and responses;
• tcp.flags.reset == 1 — packets with the connection reset flag;
• ip.addr == 203.0.113.10 — traffic to/from a specific address.

The command Follow → TCP Stream in the context menu collects packets of a single connection into a sequential conversation.

Don’t confuse the two types of filters: capture filters (BPF syntax, like in tcpdump: port 443) determine what gets into the file, while Wireshark display filters (tls.handshake) only hide the irrelevant parts of already recorded data. Their syntaxes are different.

When to use each tool

Common mistakes

1. Running without root privileges — capturing on an interface requires sudo or appropriate permissions.
2. Capturing on the wrong interface — on a server with multiple interfaces, VPN or Docker, traffic may not go through eth0. List interfaces with tcpdump -D, capture on all interfaces with -i any.
3. Recording without limits — without -c or -G the file on a busy server grows very quickly.
4. Confusing capture and display filters — they use different syntaxes.
5. Expecting to see HTTPS contents — in encrypted traffic you can see addresses, ports, the handshake and the site’s name in SNI, but not the request contents.
6. Intercepting someone else’s traffic — capture only your own systems’ traffic or do it with the owner’s permission.

Conclusion

Packet analysis is the last diagnostic step when other utilities don’t provide an answer. It shows what actually happens in the connection: who is tearing down the connection, at which stage the TLS handshake fails, whether responses arrive. To practice, it’s useful to record and analyze a normal request to a website: the DNS query, TCP connection setup, and TLS handshake.

For testing individual connections manually, netcat is useful.

Resources

• tcpdump (man)
• sngrep (GitHub)
• Wireshark: Display Filters