What does tcpdump's -s snapshot length control, what is its default in tcpdump 4.99, and when should you lower it?
answer
- bytes kept per packet
- a quarter of a mebibyte
- zero means the default
- headers only, by choice
basics
~20 sThe snapshot length is how many bytes tcpdump keeps from each packet; tcpdump 4.99 defaults to 262144, effectively whole packets. Lower it to keep headers only when payload must not be stored or the capture must be cheaper.
solid answer
~40 s`-s` (`--snapshot-length`) sets the maximum bytes kept from each packet. tcpdump 4.99 defaults to 262144 bytes, which keeps whole packets on ordinary interfaces, and `-s 0` means that same default, so old advice to always add `-s 0` is now redundant. Anything past the limit is discarded at capture time: printed lines show `[|proto]`, and Wireshark marks such frames as size-limited, with no way to recover the bytes. Lower it, to a few hundred bytes for example, when you only need headers: payloads must not reach disk, a long or rotating capture must cover more time, or the host is dropping packets. The man page notes that larger snapshots effectively reduce buffering and can cause loss.
go deeper
Know that the snapshot length is bytes kept per packet, that tcpdump 4.99 defaults to 262144 and that -s 0 means the same default.
Explain what truncation looks like ([|proto], a size-limited frame in Wireshark), why it is irreversible, and how to compute a headers-only value from the headers you need.
Show the judgement: a headers-only snaplen for privacy and long retention, the man page's warning that big snapshots reduce effective buffering, and recording the choice with the evidence.
Connect snaplen to data-handling policy: which captures may hold payloads at all, who approves full-packet capture on production, and how long such files may be kept.
## What the snapshot length is The **snapshot length** (snaplen) is the maximum number of bytes tcpdump keeps from each packet. libpcap copies at most that many bytes into its buffer and into the savefile; the rest of the packet is discarded at capture time and can never be recovered from the file. The packet's original length is still recorded, so readers can tell that a packet was cut. ## The default in tcpdump 4.99 - With no `-s`, tcpdump 4.99 uses **262144 bytes**, which in practice keeps whole packets on normal interfaces. The source says the value was chosen to fit maximum-size Linux loopback packets and some USB captures, while staying small enough that programs sizing buffers from a file's header do not try to allocate huge amounts of memory. - `-s 0` sets the same default, kept "for backwards compatibility". Old tutorials insist on `-s 0` because the default used to be a short, header-only snapshot; tcpdump 4.1 made the default the maximum, and a later release raised it to 256K. In 4.99, `-s 0` is redundant, not harmful. - The long form is `--snapshot-length=`. ## What truncation looks like - In tcpdump's printed output, a packet cut short shows `[|proto]`, naming the protocol level at which decoding ran out of bytes, such as `[|tcp]`. - When the same file is opened in Wireshark, the frame carries the message `[Packet size limited during capture]`. The Wireshark user guide's only remedy is to capture again with a larger limit. - Reassembly cannot fill the gap, because the missing bytes never reached the file. ## Why you would lower it | Reason | What a short snaplen buys | What it costs | |---|---|---| | Data minimisation | payloads (credentials, personal data, documents) never reach disk | no application-layer analysis | | Disk and retention | a long or rotating capture covers far more time per gigabyte | the same | | Capture performance | less copying per packet, fewer kernel drops | the same | tcpdump's man page states the performance trade-off directly: larger snapshots increase the time it takes to process packets and **effectively decrease the amount of packet buffering**, which may cause packets to be lost; smaller snapshots discard data from protocols above the transport layer, which may be exactly what you needed. ## Choosing a number 1. Decide what question the capture must answer. Handshake timing, resets, retransmissions and window behaviour need headers only; an HTTP status line or a DNS answer needs payload. 2. Add up the headers you must keep: the link layer (14 bytes of Ethernet, 4 more per VLAN tag), the IP header (20 bytes for IPv4 without options, 40 for IPv6 plus any extension headers) and the TCP header (20 bytes, up to 60 with options). Tunnels such as VXLAN or GRE put a whole outer set of headers in front. 3. Leave a margin. A few hundred bytes, such as `-s 256`, keeps the headers of ordinary TCP traffic. The man page's advice is to use the smallest number that still captures the protocol information you are interested in. 4. Record the value with the capture, so whoever analyses it knows why payloads are missing and does not chase a phantom bug. ## Checking what a file was captured with When tcpdump reads a savefile, it prints a header line to standard error that names the link type and the snapshot length, for example `reading from file edge.pcap, link-type EN10MB (Ethernet), snapshot length 262144`. A live capture prints the same facts when it starts: `listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes`. - That one line tells you whether the file could contain payloads at all before you spend time looking for them. - A capture taken with `-s 128` can neither support nor refute a claim about what an HTTP body contained. - A cooked link type (`LINUX_SLL2`, "Linux cooked v2") instead of Ethernet tells you the capture was taken on the Linux `any` device. ## Common confusions - Snaplen limits **bytes per packet**, not the number of packets; that is `-c`. - It is not the MTU, and it is not the OS capture buffer (`-B`), although a large snaplen fills that buffer faster. - Cutting a file down afterwards with an editing tool shrinks it, but nothing can restore bytes a short capture never kept. - A short snaplen does not make a capture anonymous: addresses, ports and timing remain, and they can still be personal data.
- A colleague's capture shows `[|tcp]` on most lines and Wireshark complains the packets were size-limited; what happened and what do you do?The capture used a snapshot length too short for those packets, so libpcap kept only the first bytes and decoding ran out inside TCP. The missing bytes were never saved, so no tool can recover them. If the question needs them, capture again with the default (no `-s`) or a value large enough for the headers and payload you need.
- Why might lowering the snapshot length reduce `packets dropped by kernel`?Each captured packet occupies capture-buffer space and copy time in proportion to the bytes kept. The man page notes that larger snapshots effectively decrease the amount of packet buffering, so when tcpdump struggles to keep up, a headers-only snaplen lets more packets fit in the same buffer and be drained before it fills.
saying these in an interview costs you the question
- By default tcpdump keeps only the first few dozen bytes, so -s 0 is always required.
- -s 0 means capture zero bytes of each packet.
- A bigger snapshot length only costs disk space, never packets.
- Wireshark can rebuild truncated packets later through TCP reassembly.
- The snapshot length limits how many packets are captured.