skip to content

Why does Wireshark write captures as pcapng by default, and what can you lose by saving a capture as pcap instead?

level: middleimportance: nice to knowfreq 11%

answer

  1. one global header versus blocks
  2. one link-layer type per pcap file
  3. per-interface description blocks
  4. comments and drop counters
  5. editcap -F for old tools

basics

~20 s

pcapng describes each interface separately and can carry comments, name resolution and capture statistics, so one file can hold several interfaces. pcap has one global header with a single link-layer type, so mixed-interface captures cannot be saved as pcap and metadata is dropped.

solid answer

~40 s

A pcap file has one global header, so the whole file shares one link-layer type and snapshot length, and it has nowhere to put metadata. pcapng is built from blocks: an Interface Description Block per interface (name, description, capture filter, link type, snaplen, timestamp resolution), packet blocks that point to their interface, plus comment, name-resolution and statistics blocks. That is why dumpcap overrides `-F pcap` and writes pcapng whenever you capture on more than one interface, and why mergecap fails outright when asked to write mixed link types as pcap. Saving as pcap can also lose comments, name resolution and timestamp resolution. Keep pcapng as the record and convert a copy with `editcap -F pcap` only for a tool that cannot read pcapng.

go deeper

for a junior

Recall that pcapng is Wireshark's default, that pcap is the older single-header format, and that some older tools read only pcap.

for a middle

Explain the block structure: per-interface description blocks, comments, name resolution and statistics, and why several interfaces or mixed link types force pcapng.

for a senior

Show evidence discipline: capture to pcapng, annotate in the file, convert only copies for legacy tools, and state what each conversion threw away.

for a principal

Decide the retention format for captures that leave the team, balancing tool compatibility against keeping interface identity, comments and drop counts with the evidence.

## Two capture file formats **pcap** (the libpcap format) is the original: a single global header followed by packet records. The global header fixes **one link-layer type** and one snapshot length for the entire file; each record carries a timestamp, the captured length and the original length. **pcapng** ("next generation") is a sequence of typed **blocks**, and Wireshark has saved pcapng by default since version 1.8. dumpcap, tshark, editcap and mergecap all default to it as well. | Aspect | pcap | pcapng | |---|---|---| | Interfaces per file | one, implied by the global header | many, one Interface Description Block each | | Link-layer types per file | exactly one | one per interface, so mixing is fine | | Interface metadata | none | name, description, capture filter, OS, hardware, snaplen, timestamp resolution | | Comments | none | capture comments and per-packet comments | | Name resolution | not stored | optional Name Resolution Block | | Capture statistics | not stored | Interface Statistics Block with received and dropped counts | | Reader support | the lowest common denominator | current analysis tools; some older tools read only pcap | ## Why the default matters at capture time - **Several interfaces need pcapng.** dumpcap enforces it: with more than one `-i`, its `-F pcap` (or the deprecated `-P`) is overridden and the file is written as pcapng. - **Comments travel with the evidence.** `dumpcap --capture-comment` writes a capture comment when the output is a single file, and `editcap -a <framenum:comment>` annotates individual packets — useful when handing a capture to another team. - **Interface metadata explains the file.** dumpcap records each interface's name (overridable with `--ifname` and `--ifdescr`), the capture filter in force, the snapshot length and the timestamp resolution, so a later reader knows how the capture was taken. - **Drop counters can be kept.** At the end of a single-file pcapng capture, dumpcap writes an Interface Statistics Block, commented "Counters provided by dumpcap", with received and dropped counts. Wireshark's guide lists the drop count among things a capture file does not save — true of pcap, but this pcapng block does carry it. - **Decryption secrets** can also be embedded in pcapng; how that is done is a TLS-decryption subject. ## What you lose by saving as pcap 1. **Mixed link types fail outright.** mergecap's documentation warns that pcap cannot represent per-packet encapsulation and that this combination will cause the output file creation to fail — an Ethernet capture merged with an 802.11-plus-radiotap capture cannot become one pcap. 2. **Comments, name resolution and timestamp resolution may vanish.** Wireshark warns that saving in a different format can lose exactly these. 3. **Interface identity disappears.** Without interface blocks, nobody can tell which leg of a router or proxy a packet was captured on, or which capture filter shaped the file. ## When pcap is still the right call - A consumer that reads only pcap, such as an older replay tool or a legacy script. Convert a **copy** with `editcap -F pcap in.pcapng out.pcap` (or `tshark -F pcap`) and keep the pcapng original as the record. - A single-interface, uncommented capture, where nothing of value is lost. - Live capture accepts only these two: dumpcap and tshark write pcapng or pcap when capturing, and dumpcap deliberately supports fewer formats than tshark. Anything else means capture first, then convert with editcap. ## Checking what a file carries Before handing a capture over, or before converting it, look inside with **capinfos**: - `capinfos -t` shows the capture file type, so you know whether you hold pcap or pcapng. - `capinfos -E` shows the file's encapsulation; when it is per-packet, capinfos also lists each encapsulation in use with its packet count — a file that mixes link-layer types and cannot become a single pcap. - `capinfos -I` prints the detailed interface information recorded in a pcapng file: names, descriptions and the other per-interface fields. - `capinfos -k` displays the capture comment, which for pcapng is the comment stored in the section header block. Running these on the converted copy as well shows directly what the conversion discarded. ## A practical rule Capture to pcapng, always. Convert at the edge, for the one tool that needs it, and say in the hand-over note that the converted copy lost its interface metadata, comments and drop counters.

  • A colleague's script reads only pcap, but your capture covers two interfaces with different link-layer types; what are your options?
    One pcap cannot hold both link-layer types, so split rather than convert: extract each interface's packets into its own file and convert each copy with `editcap -F pcap`, or ask whether the script can be pointed at a tool that reads pcapng. Keep the original pcapng as the record, since the split copies no longer show how the two legs line up.
  • Where should a note such as 'captured on the WAN leg during the 03:12 stall' go so it survives a hand-over?
    Into the pcapng file itself: a capture comment written with `dumpcap --capture-comment` at capture time, or packet comments added afterwards with `editcap -a` or in Wireshark. Both live only in pcapng; a pcap copy silently drops them.

saying these in an interview costs you the question

  • pcap and pcapng hold the same information; the extension is cosmetic.
  • A pcap file can mix Ethernet and 802.11 packets as long as each is labelled.
  • dumpcap obeys -F pcap even when capturing on two interfaces.
  • Saving as pcap keeps packet comments, just in a different place.