How to track lost network packets with tcpdump

Why intermittent network failures challenge administrators

When an application on a Linux server drops connections sporadically, the issue often feels like a ghost. Restarting the service resolves it for a few minutes, but the failure returns without warning. In production environments where thousands of packets flow every second, relying on guesswork is the fastest path to stress. This exact scenario is where tcpdump shines as a classic command-line tool capable of listening to everything passing through the network interface.

Before diving into complex commands, remember that we covered initial capture fundamentals in the article about how to use tcpdump on Linux to capture network packets. However, when the challenge is isolating problems that happen only once a day, capturing all traffic generates massive files impossible to analyze manually. The secret to modern network engineering is not recording everything, but using surgical filters to fish out errors in an ocean of data.

Mastering BPF filter syntax on Linux servers gives administrators unprecedented precision. The core power of tcpdump lies in Berkeley Packet Filter support, an embedded language telling the Linux kernel which packets to record in memory and which to ignore. In practice, this means saving CPU cycles and avoiding gigabytes of useless traffic when troubleshooting stubborn connection drops.

Isolating TCP flags to catch connection resets

Packet loss does not always happen because a cable was unplugged or a router failed. Often, connections are abruptly terminated due to firewall timeouts, buffer overflows, or routing instability. To spot these anomalies, we must inspect TCP flags, which act as small traffic signals exchanged between machines to open, maintain, and close digital conversations.

When a connection is forcefully rejected, the operating system sends a packet with the RST (Reset) flag enabled. If you want to track the exact moment this occurs, you can filter tcpdump to display only packets containing this specific flag. Here is how to structure this advanced filter directly in your command line:

tcpdump -i eth0 'tcp[tcpflags] & (tcp-rst) != 0'

This mathematical query examines the flag byte of the TCP header and isolates any forced termination event. If these packets appear frequently during peak hours, you have mathematical proof that the issue is not the application itself, but an intermediate infrastructure component dropping active sockets.

Tracking excessive retransmissions and hidden latency

Another classic symptom of degraded networks is high packet retransmission rates. When a packet gets lost along the path, the sender waits for a timeout and transmits the data again. Although the final application eventually recovers the information, the cost in latency and CPU consumption is massive. Isolating this behavior requires capturing traffic and searching for repetitive patterns.

To monitor duplicated or delayed packets, we can combine host filters with sequence analysis. If you suspect a specific server, say 192.168.1.50, the following instruction restricts the capture strictly to it, allowing you to save the result into a binary file for further analysis with graphical tools:

tcpdump -i eth0 -w losses.pcap host 192.168.1.50 and not port 22

Notice the use of the logical operator 'not port 22'. It is essential to exclude your own administrative SSH session, ensuring the pcap file contains only useful application data under investigation. This limitation prevents noise and makes diagnosis much faster and more accurate.

Best practices for continuous recording in production

Running tcpdump on production servers requires extreme caution. If traffic is intense and the disk is slow, the recording process itself can exhaust system resources and crash the application. Therefore, experienced professionals use size limits and file rotation to capture intermittent events without destabilizing the environment.

A very useful technique consists of limiting captured packets or splitting recording into time blocks. The following command records packets in 100-megabyte batches, keeping only the most recent files on disk:

tcpdump -i eth0 -C 100 -W 5 -w /tmp/network_capture.pcap 'tcp[tcpflags] & (tcp-syn) != 0'

This approach ensures that if the problem happens overnight, you will have the exact record saved on disk without risking filling up the server's root partition with unnecessary gigabytes of data. To complement this implementation in production environments, see our related technical analyses on How to test BIOS chip voltage on motherboards with a multimeter and How to repair corrupted GPT partition tables with gdisk.

Final considerations

Tracking lost packets in Linux networks stops being a mystery when you combine precise BPF filters, TCP flag analysis, and production-safe recording practices. Tcpdump remains one of the most powerful and efficient tools in the open-source ecosystem to unveil the true behavior of data in transit. Mastering this technique guarantees fast and accurate diagnoses, turning intermittent frustrations into definitive technical resolutions.