tcpdump Snapshot Length: Control Bytes Captured per Packet (2026)

The amount of data tcpdump captures for each packet isn’t a fixed, arbitrary number; it’s a deliberate setting that balances capturing enough detail with managing storage and performance.

Let’s see tcpdump in action. Imagine you’re troubleshooting a slow connection, and you want to see the actual data payloads.

First, let’s capture some packets without specifying a snapshot length. tcpdump defaults to a reasonably large snapshot length (often 65535 bytes), which means it will try to capture the full packet payload if it fits within that limit.

sudo tcpdump -i eth0 -w capture.pcap

Now, let’s say you’re only interested in the TCP/IP headers to analyze timing and sequence numbers, but not the actual data. Capturing the full data can generate huge files and slow down analysis. We can limit the snapshot length.

sudo tcpdump -i eth0 -s 96 -w capture_headers_only.pcap

Here, -s 96 tells tcpdump to only capture the first 96 bytes of each packet. This is typically enough to get the Ethernet header, IP header, and TCP header.

The Problem Solved

The core problem tcpdump’s snapshot length addresses is information overload and resource consumption. Network traffic can be voluminous, and capturing every single byte of every packet can quickly:

• Fill up disk space: Gigabytes of packet data can be generated in minutes.
• Impact network performance: The capturing machine has to process and write a lot of data, potentially becoming a bottleneck itself.
• Slow down analysis: Sifting through massive .pcap files in tools like Wireshark is tedious and time-consuming.

By allowing you to specify a snapshot length, tcpdump lets you tailor the capture to your specific needs. You can decide whether you need full packet payloads, just headers, or something in between.

How it Works Internally

When tcpdump (or more accurately, the libpcap library it uses) receives a packet from the kernel’s network interface, it requests a certain number of bytes from the interface driver. This number is determined by the -s (snapshot length) option.

• If the packet is smaller than the snapshot length: The entire packet is captured.
• If the packet is larger than the snapshot length: Only the first snapshot length bytes are captured. The rest of the packet is truncated.

This truncation is crucial. tcpdump doesn’t magically stop the packet from arriving at its destination or on the wire; it simply tells libpcap to stop reading from the buffer after a certain number of bytes. The kernel interface driver still handles the full packet for delivery.

Controlling the Bytes Captured

The primary lever you have is the -s option.

• -s 0 (or -s 65535 on older systems): This is the default and instructs libpcap to capture the maximum possible bytes per packet, typically the full MTU of the interface (often 1500 bytes for Ethernet, but can be larger for jumbo frames). Use this when you need to inspect application-layer data, like the contents of an HTTP request or the payload of a database query.

  sudo tcpdump -i eth0 -s 0 -w full_capture.pcap
  

• -s 96: As shown before, this is a common value for capturing just the headers. It usually covers:

  • Ethernet Header: 14 bytes
  • IP Header: 20 bytes (standard IPv4, can be up to 60 bytes with options)
  • TCP Header: 20 bytes (standard, can be up to 60 bytes with options)
  • Total: ~54-100 bytes. 96 bytes is a safe bet to capture most common header combinations. This is excellent for analyzing network-level issues like packet loss, retransmissions, and RTT.

  sudo tcpdump -i eth0 -s 96 -w headers_only.pcap
  

• -s 128 or -s 256: These values might be useful if you need to see the first few lines of an HTTP request or response, or a small chunk of application data, but still want to keep file sizes manageable.

• -s <specific_value>: You can pick any value. For example, if you know your application protocol has a fixed 32-byte header, you might use -s 32 to capture only that, plus the network headers.

Important Note: When you specify a snapshot length smaller than the actual packet size, tcpdump will mark the packet as truncated in its output or in the .pcap file metadata. Wireshark will often indicate this with a "Packet is truncated" message.

The snapshot length is not a filter; it’s a capture size limit. tcpdump will still see and process packets that are larger than the snapshot length, but it will only store the initial portion.

If you try to analyze a .pcap file captured with a small snapshot length and discover you’ve truncated critical application data, you’ll need to re-capture the traffic with a larger snapshot length, typically -s 0.

The next challenge you’ll likely face is efficiently filtering this captured data, especially when dealing with high-volume traffic.