Servers with intermittent latency? How to debug bottlenecks with tcpdump and Wireshark
Learn how to diagnose corrupted packets and sudden slowness spikes on Linux server interfaces using practical tcpdump and Wireshark techniques.
Summary
- Raw packet capture with tcpdump reveals the true state of network traffic before any interference from upper layers.
- CRC errors and truncated packets usually indicate physical faults in cables, switch ports, or network card drivers.
- Intermittent latency manifests in captures through frequent retransmissions and suddenly shrinking TCP windows.
- Wireshark turns complex PCAP files into intuitive IO graphs and temporal handshake sequence diagrams.
- Correlating network hardware metrics with packet analysis prevents false positives in infrastructure diagnostics.
Why your Linux server network is suddenly failing
When an application starts showing intermittent slowness or unexplained disconnections in system logs, the root cause usually hides deep within the network stack. Often, we investigate databases, memory usage, or CPU load while ignoring that data packets are dropping or arriving corrupted along the way. In practice, this means the server's network interface or intermediate networking hardware is suffering from physical interference, driver bugs, or buffer exhaustion. Understanding what is really happening on the wire requires looking directly at the binary flow using native tools.
To capture this raw traffic without hurting machine performance, we use tcpdump, a command-line utility that intercepts and displays packets transmitted or received by a network interface. It acts like a wiretap for the operating system, recording each packet into files known as PCAP files. These files can later be analyzed in powerful graphical environments like Wireshark. Before starting any deep investigation, keep in mind that data flow stability relies on both logical health and physical link integrity, something we also address when you track high-frequency ripple and noise on the bench during hardware testing.
How to capture traffic on production servers without crashing the system
Running packet captures on busy servers requires caution, because writing gigabytes of data to disk can exhaust storage or overload the CPU. The best approach is to filter traffic right at the source, isolating only suspicious packets. The tcpdump command lets you specify interfaces, ports, and IP addresses to limit the collection scope. In practice, this prevents the generated file from becoming gigantic and impossible to open later.
To perform a safe capture on a specific interface while writing data to a dedicated file for later analysis, you can follow these steps in your Linux server terminal:
- Identify the exact name of the active network interface by running the network interface listing command.
ip link show - Start the capture, routing traffic from the primary interface to a dedicated file while limiting the size of each packet to save only headers if needed.
sudo tcpdump -i eth0 -w network_diagnostics.pcap -C 100 -W 5 - Stop the capture execution after reproducing the slowness scenario by pressing the keyboard interrupt combination in your terminal.
Ctrl + C
With the PCAP file saved, you have an exact snapshot of network behavior during the problem peak. If your server is also suffering from excessive power draw due to heavy processing spikes, it is worth crossing this data with hardware energy consumption, as detailed in our guide on how to calculate real server power consumption under operational stress.
Identifying corrupted packets and hidden hardware errors
When packets arrive corrupted, the TCP protocol discards the data and requests a retransmission, triggering that annoying feeling of intermittent lag. In Wireshark, corrupted packets often appear with red or black warnings, pointing out incorrect checksums. A checksum is a mathematical calculation made at the source and checked at the destination; if the numbers do not match, the packet was altered midway.
These alterations are usually caused by faulty cables, oxidized connectors, broken switch ports, or even issues within the server's network card controller. When the bug lies in the network card driver or hardware offloading, the operating system might try to calculate the checksum incorrectly. Temporarily disabling the checksum offload feature for testing can isolate the failure:
sudo ethtool -K eth0 rx off tx offIf the errors disappear after this adjustment, the culprit is the network card driver or physical adapter firmware, requiring an urgent update to stabilize traffic.
Diagnosing intermittent latency and TCP window bottlenecks
Another classic symptom of issues in Linux interfaces is intermittent latency that appears out of nowhere and vanishes moments later. To track this down, open the PCAP file in Wireshark and use the TCP conversation flow analysis tool, accessible from the statistics menu. Look for excessive delays between a sending packet (SYN or ACK) and its corresponding response. If the timeline graph shows absurd jumps from milliseconds to seconds, the bottleneck is in the network or the operating system buffer.
Often, the TCP window size drops dramatically, indicating that the receiving application cannot read data as fast as it arrives. This chokes the connection and creates invisible queues on the network interface. Tuning Linux kernel socket buffers in the sysctl.conf file usually relieves this pressure, allowing the server to handle larger traffic spikes without dropping packets due to memory limits.
Conclusion and best practices in Linux network debugging
Deep packet analysis with tcpdump and Wireshark turns an invisible problem of intermittent lag into a clear, evidence-based diagnosis. Instead of guessing the root cause based purely on assumptions, infrastructure engineers can pinpoint exactly where a packet was corrupted or where latency began to pile up. Mastering these tools brings greater server resilience and prevents prolonged outages in critical production environments.
Maintaining a routine of preventive monitoring and validation for cables, drivers, and kernel settings closes the door on silent failures. By combining physical bench inspections with logical packet analysis, your infrastructure gains the robustness required to operate under any demand without losing performance.