Wireshark — Admin Guide

Audience: administrators, architects, and developers who deploy, operate, secure, extend, or build Wireshark. This guide is deliberately exhaustive — it aims to be a complete, source-based reference. End-user task walkthroughs live in the User Guide; this guide links there rather than repeating them.

Documented version: Wireshark 4.7.2 (CMakeLists.txt: PROJECT_MAJOR_VERSION 4, PROJECT_MINOR_VERSION 7, PROJECT_PATCH_VERSION 2).

1. Executive Summary

What it is. Wireshark is the industry-standard open-source network protocol analyzer. It captures live traffic (via libpcap/Npcap) or reads saved captures, dissects them with a large protocol engine into a filterable field tree, and presents them through a Qt GUI or a family of command-line tools. It is authored by Gerald Combs and hundreds of contributors, copyright 1998, and is distributed under the GNU GPLv2.

What it's built with. A CMake-driven C17/C++17 codebase. Core libraries: GLib (≥ 2.54), GCrypt (≥ 1.8) for cryptography, libpcap/Npcap for capture, and Qt 6 (≥ 6.2) for the GUI. Optional: GnuTLS (≥ 3.5.8, TLS decryption), zlib/zlib-ng, LZ4 (≥ 1.8), Zstandard (≥ 1.0) for compressed captures, plus libsmi (SNMP MIBs), MaxMindDB (GeoIP), and others. An embedded Lua interpreter provides scriptable dissectors and taps.

Deployment shape. Wireshark is a desktop / workstation application, not a network service. There is no server process, no listening socket, no user database, and no network-facing API in the deployed product. The one daemon-style component, sharkd, is a local JSON-RPC back-end used by front-ends, not a network service. Consequently the operational concerns here are packaging and distribution, capture-privilege management, attack surface of the dissectors, and configuration/profile management across a fleet — not uptime, scaling, or load balancing.

Operational burden. Low for a single workstation (install a package, join the wireshark group). Moderate at fleet scale, where the concerns are consistent profiles/preferences, controlling who may capture, keeping the (large, frequently-updated) dissector code patched, and — for automated pipelines — running tshark/dumpcap/editcap safely against untrusted capture files.

Important

Wireshark's threat model is inverted from a typical server's: the danger is not attackers reaching a service, but a malicious or malformed packet/capture exploiting a dissector while an analyst inspects it. Almost every hardening recommendation in §6 Security follows from that.

2. Architecture

Wireshark is a set of layered libraries with several front-ends (GUI, CLI tools) built on top. Every front-end shares the same capture, file-I/O, and dissection code.

2.1 Component diagram

                         ┌───────────────────────── Front-ends ─────────────────────────┐
                         │                                                               │
   ┌──────────┐   ┌──────────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌───────────────┐
   │ wireshark│   │   tshark     │  │ editcap  │  │ mergecap │  │ capinfos │  │ sharkd (JSON- │
   │ (Qt GUI) │   │  rawshark    │  │ text2pcap│  │ reordercap│ │ captype  │  │ RPC back-end) │
   │ ui/qt    │   │  ui/cli      │  │ (file    │  │  (file   │  │  (file   │  │               │
   │ ui/strato│   │  taps        │  │  tools)  │  │  tools)  │  │  tools)  │  │               │
   └────┬─────┘   └──────┬───────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘  └──────┬────────┘
        │                │               │             │             │              │
        └────────────────┴───────────────┴─────────────┴─────────────┴──────────────┘
                                          │
        ┌─────────────────────────────────┼─────────────────────────────────┐
        │                                 │                                 │
   ┌────▼──────┐                    ┌─────▼──────┐                     ┌─────▼──────┐
   │  capture  │  live packets      │   epan     │  dissection engine  │  wiretap   │  file read/write
   │  engine + │───────────────────▶│ (libwire-  │◀────────────────────│ (libwiretap│
   │  dumpcap  │  (privileged)      │  shark)    │  packets from files │  many fmts)│
   └────┬──────┘                    └─────┬──────┘                     └─────┬──────┘
        │                                 │                                  │
   ┌────▼──────┐   ┌───────────────────────────────────────────────┐   ┌────▼──────┐
   │ libpcap / │   │ epan sub-systems:                             │   │ writecap  │
   │  Npcap    │   │  • dissectors/  (2000+ protocol dissectors)   │   │ (capture  │
   └───────────┘   │  • dfilter/     (display-filter engine)       │   │  writers) │
                   │  • ftypes/      (field type system)           │   └───────────┘
   ┌───────────┐   │  • wmem         (memory pool allocator)       │
   │  extcap/  │   │  • wslua/       (Lua binding layer)           │   ┌───────────┐
   │ external  │   │  • crypt/       (protocol crypto)             │   │  wsutil   │
   │ capture   │   └───────────────────────────────────────────────┘   │ (shared   │
   │ programs  │                          ▲                             │  utils)   │
   └───────────┘                          │                             └───────────┘
                              ┌───────────┴───────────┐
                              │  plugins/epan/*       │  loadable dissectors
                              │  (profinet, opcua, …) │  + Lua plugins
                              └───────────────────────┘

2.2 Component inventory

2.3 Data flow

1. Ingest. Packets arrive either live (capture engine → dumpcap → libpcap/Npcap or an extcap program) or from a file (wiretap auto-detecting format and decompression).
2. Dissect. epan walks the byte stream layer by layer; each dissector claims its bytes and delegates the remainder, building a typed protocol tree.
3. Filter/colorize. The dfilter engine evaluates display filters and coloring rules against that tree.
4. Present or persist. Front-ends render the tree (GUI panes, TShark text/JSON/XML) and/or wiretap/writecap writes packets back out.

2.4 Data Layer

Wireshark has no database. Its "data layer" is:

• Capture files on disk (native pcapng, plus pcap and dozens of third-party formats), read/written by wiretap. pcapng blocks carry interfaces (IDB), packets, name-resolution records (NRB), and decryption secrets (DSB).
• Compiled reference tables — IANA services, IEEE OUI/manuf, enterprise numbers — are compiled into the binary for fast startup (dumpable at runtime with tshark -G services|manuf|enterprises).
• User configuration files (preferences, filters, name-resolution overrides, profiles) under the personal/global config directories — see §4.

2.5 Caching

• wmem memory pools provide scoped allocation (per-packet, per-file, per-capture) so the engine can free an entire scope at once rather than tracking individual objects — the primary in-memory "cache" discipline.
• Compiled-in tables (above) act as a startup cache of otherwise-file-based reference data.
• Name-resolution results are cached in memory during a session; captured DNS/SNI observations and the hosts/ethers/services files seed resolution.
• There is no external cache (no Redis/memcached) — this is a desktop application.

3. System Requirements

3.1 Build/runtime dependencies

Note

Optional libraries are toggled at configure time (e.g. cmake -DENABLE_ZLIB=OFF, -DENABLE_LZ4=OFF, -DENABLE_ZSTD=OFF, -DENABLE_SMI=OFF). If a library is absent, Wireshark still builds but silently omits that capability. Confirm what a given binary has with wireshark -v / tshark -v.

3.2 Operating systems

The project builds and tests regularly on Linux (Ubuntu), Microsoft Windows, and macOS. Official installer packages exist for Windows and macOS; distro packages exist for Debian, Ubuntu, Fedora, CentOS, RHEL, Arch, Gentoo, openSUSE, FreeBSD, DragonFly BSD, NetBSD, and OpenBSD, plus pkgsrc, OpenCSW, Homebrew, and MacPorts. It runs on other Unix-like systems (Solaris, HP-UX, AIX) with more effort. OS-specific notes are in README.linux, README.macos, README.bsd, README.msys2, and README.DECT.

3.3 Hardware guidance

There are no hard minimums, but capture and analysis are memory- and I/O-bound:

• RAM scales with capture size and dissection depth — very large captures or two-pass analysis can consume gigabytes. Prefer trimming/splitting large files (editcap) over loading them whole in the GUI.
• Disk throughput bounds sustained capture rates; use ring buffers to cap disk use.
• Capture buffer (-B, default 2 MiB) governs drop resistance on fast links; raise it for high-rate capture.
• The GUI benefits from fast random-seek within capture files — GZIP and LZ4 (independent-block) support fast seeking; Zstd/other do not.

4. Configuration Mastery

Wireshark is configured through text files in a global (system-wide) directory and a personal directory. Global files are read first; personal files override them; -o command-line overrides win over both. Zero configuration keys were extractable via static analysis (preferences are runtime-registered by each dissector/module, not stored in a manifest), so the authoritative list of preference names is obtained at runtime:

tshark -G defaultprefs      # a complete default preferences file
tshark -G currentprefs      # the effective current preferences
tshark -G folders           # where every config/data folder resolves to

4.1 Configuration directories

Override the personal directory with WIRESHARK_CONFIG_DIR; override data/plugin/extcap locations with WIRESHARK_DATA_DIR, WIRESHARK_PLUGIN_DIR, WIRESHARK_EXTCAP_DIR. These overrides are ignored when the program runs setuid/root.

4.2 Configuration files reference

All settings files are plain text. # starts a comment.

Warning

For cfilters, dfilters, dmacros, and colorfilters, global and personal files are not merged — if a personal file exists it is used alone; the global file applies only when no personal file exists. Plan fleet defaults accordingly (ship them personal, or ensure users have no personal copy).

Caution

Saving preferences, disabled-protocols, or filters from the GUI overwrites the corresponding personal file and destroys any comments or unknown/obsolete keys in it. Manage such files with configuration management, not hand-edits users will clobber.

4.3 Preferences precedence

compiled defaults  →  global preferences  →  personal preferences  →  personal recent  →  -o overrides

Set a preference for one run with -o prefname:value (repeatable). UAT (User Access Table) entries use -o "uat:<file>:<record>". Name-resolution flags -n/-N override resolution preferences including those set via -o.

4.4 Environment variables

See the User Guide for the user-facing subset. The complete set includes the WIRESHARK_*_DIR overrides, WIRESHARK_RUN_FROM_BUILD_DIRECTORY, the logging variables (WIRESHARK_LOG_LEVEL, WIRESHARK_LOG_DOMAINS, WIRESHARK_LOG_FATAL, WIRESHARK_LOG_DEBUG, WIRESHARK_LOG_NOISY), format-detection tuning (ERF_RECORDS_TO_CHECK, IPFIX_RECORDS_TO_CHECK, both default 20), the developer abort switches (WIRESHARK_ABORT_ON_DISSECTOR_BUG, WIRESHARK_ABORT_ON_TOO_MANY_ITEMS), WIRESHARK_QUIT_AFTER_CAPTURE, and WIRESHARK_DEBUG_WMEM_OVERRIDE (force a wmem allocator backend for debugging).

4.5 Profiles

A configuration profile is a named directory of the above files. Profiles let one workstation carry different preference/filter/coloring sets (e.g. "Troubleshooting", "VoIP"). Select with -C <profile>; TShark's --global-profile loads the named profile from the global directory. List profiles with tshark -G profiles. Profiles are the primary unit for distributing standardized configurations across a team.

5. Deployment

Wireshark is deployed as installed software on endpoints, not as a service. "Deployment" here means packaging, distribution, and fleet configuration.

5.1 Distribution channels

• Official installers — Windows (.exe, bundles Npcap) and macOS (.dmg). Packaging sources live under packaging/ (nsis, wix, msys2 for Windows; macosx for macOS; debian, rpm for Linux; portableapps, appimage).
• Distro packages — apt/dnf/pacman/etc. (see §3.2); packagers apply the capture-privilege model for the platform.
• From source — CMake build; see §10.1 and the INSTALL/README._OS_ files.

5.2 Fleet configuration strategy

1. Standardize with a global config directory. Ship a global preferences, dfilters, cfilters, colorfilters, and disabled_protos in <install>/share/wireshark. Remember global disables of protocols are not user-overridable — useful for policy (see §6.4).
2. Distribute profiles for role-specific setups.
3. Control capture rights centrally (group membership / capabilities — see §6).
4. Pin versions and roll updates promptly — dissector CVEs are frequent (below).

5.3 CI/CD

Wireshark's own CI is GitLab-based (bug tracker and repo at gitlab.com/wireshark/wireshark). For your automated pipelines that use Wireshark (e.g. processing captures in CI):

• Use the CLI tools headlessly — no Qt needed. tshark, editcap, capinfos run fine in containers.
• Treat every input capture as untrusted (see §6.2); run in a sandbox/container with no network and least privilege.
• For fuzzing your own dissectors, the repo ships fuzz/ and tools/oss-fuzzshark, and editcap -E <prob> injects random errors to generate malformed inputs.

6. Security

Wireshark has no authentication, authorization, TLS termination, or session management — it is not a networked service, so those concepts do not apply and are intentionally omitted here. Its real security model has three pillars: capture-privilege isolation, the dissector attack surface, and handling of decryption secrets.

6.1 Capture-privilege isolation (the core control)

Live capture needs elevated privileges (raw socket / device access). Wireshark isolates this into dumpcap, a small, auditable program; the GUI and TShark invoke it rather than opening interfaces themselves.

Caution

Do not run the Wireshark GUI or TShark as root, and do not make them setuid. The project explicitly warns against it. The correct model is to give capture rights only to dumpcap.

Recommended per-platform setup:

• Linux (Debian/Ubuntu): answer Yes to "Should non-superusers be able to capture packets?" during install (or dpkg-reconfigure wireshark-common). This restricts dumpcap to the wireshark group via file permissions/capabilities; add trusted analysts to that group.
• Linux (manual): grant capabilities to dumpcap (setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap) and restrict its group.
• BSD/Solaris/HP-UX: grant access to the appropriate /dev capture entry (DLPI/BPF).
• Windows: Npcap provides the capture driver; its installer offers an option to restrict raw capture to Administrators.

The WIRESHARK_*_DIR environment overrides are deliberately ignored under root/setuid, preventing a privileged process from being redirected to attacker-controlled plugins or data.

6.2 Dissector attack surface

The dissectors parse untrusted, attacker-influenced input (that is their job). A malformed packet or capture file can trigger a bug in a dissector. This is the primary risk when analyzing captures from the wild.

Mitigations:

• Keep Wireshark current. Dissector fixes ship constantly; treat updates as security updates.
• Analyze untrusted captures on an isolated/sandboxed host with no sensitive data and no network.
• Disable dissectors you don't need to shrink the surface (see §6.4).
• Prefer the CLI for triage — capinfos/tshark -q do less rendering than the full GUI.
• Developer aids: WIRESHARK_ABORT_ON_DISSECTOR_BUG and WIRESHARK_ABORT_ON_TOO_MANY_ITEMS turn dissector misbehavior into an immediate, debuggable abort; the fuzz/ harness and oss-fuzzshark fuzz dissectors continuously.

6.3 Decryption secrets and sensitive data handling

Wireshark can decrypt many protocols, which means it handles key material:

• TLS/SSH/WireGuard/OPC UA/ESP keys can be supplied via protocol preferences or embedded into a capture as a Decryption Secrets Block (DSB) with editcap --inject-secrets <type>,<file>. Extract them with editcap --extract-secrets, and strip them before sharing a capture with editcap --discard-all-secrets.
• Kerberos keytabs load via -K <keytab> (dissection option).
• Name-resolution records (NRB) embedded in pcapng can leak internal hostnames; remove with editcap --discard-name-resolution.
• Capture/packet comments may contain sensitive notes; strip with editcap --discard-capture-comment / --discard-packet-comments.

Warning

Captures frequently contain credentials and payloads in cleartext (tshark -z credentials will surface FTP/HTTP/IMAP/POP/SMTP logins). Treat capture files as sensitive artifacts: store them encrypted, scrub secrets/NRB/comments before distribution, and never attach captures with sensitive data to public bug reports.

6.4 Reducing attack surface (protocol enablement)

Ship a global disabled_protos to permanently disable dissectors your environment never needs (global disables cannot be re-enabled by users). At runtime, --disable-protocol ALL --enable-protocol eth,ip,... restricts dissection to a whitelist for a single run — useful in automated pipelines processing untrusted files.

6.5 Input validation and network exposure

• Network exposure: none in normal operation — Wireshark listens on no port. Remote-capture paths that do touch the network are opt-in: rpcap:// interfaces (libpcap remote capture, with -A user:password auth) and extcap SSH tools (sshdump, ciscodump, sshdig). Audit and restrict these where enabled.
• sharkd speaks JSON-RPC over stdio/local socket for front-ends; it is not intended as a network-exposed service — do not expose it.
• Input validation is inherent to dissection; the hardening posture is patching + sandboxing + disabling unneeded dissectors, not a config toggle.

7. Operations

Wireshark has no service lifecycle (no start/stop/health endpoints). Operational tasks center on capture management and log/diagnostics.

7.1 Running capture "operationally"

For unattended, long-running capture use dumpcap directly (lowest overhead, least privilege) with a ring buffer:

dumpcap -i eth0 -b filesize:102400 -b files:24 -w /var/captures/roll.pcapng

Bound resources with autostop (-a duration:, -a filesize:) and disable name resolution (-n) for high rates. See the User Guide for the full option catalog.

7.2 Logging

Console diagnostics are controlled by the --log-* options (and matching WIRESHARK_LOG_* env vars), shared by all tools:

7.3 Monitoring & Health Checks

There is no daemon to health-check. Operationally you monitor capture health:

• dumpcap -S prints per-interface packet statistics once per second.
• During capture, drop counts indicate the buffer (-B) is too small or dissection can't keep up.
• Post-capture, capinfos reports counts, rates, duration, and whether packets are in strict chronological order (-o).

7.4 Backup & Restore

The artifacts worth backing up are capture files and the configuration/profile directories (§4.1). Config files are plain text and trivially version-controllable — the recommended way to manage them across a fleet. There is no database or stateful store to back up.

7.5 Upgrades & capacity

• Upgrades: replace the package; treat updates as security-relevant (dissector fixes). Preferences are forward-compatible text; the pre-4.4 dfilter_macros file is auto-migrated to dmacros on first run.
• Capacity: "capacity" is per-workstation memory/disk. Manage large captures by splitting/trimming (editcap) rather than loading whole; cap live capture with ring buffers.

8. Performance Tuning

Tip

The single most effective tuning step for live capture is to capture with dumpcap and a capture filter, then analyze the saved file offline — it separates the latency-sensitive capture from the CPU-heavy dissection.

9. Integrations

9.1 Plugin / Extension System

Wireshark loads extensions from a personal and a global plugin folder. Layout:

• Binary plugins: <plugindir>/X.Y/<type>/ where X.Y is the Wireshark minor version and <type> is epan (libwireshark dissectors/taps), wiretap (file readers), or codecs.
• Lua plugins: placed directly in the plugin folder (or, on Unix, in $XDG_CONFIG_HOME/wireshark/plugins).

A plugin module may register multiple protocols; plugin protocols are enabled/disabled like built-ins. List loaded plugins with tshark -G plugins. Bundled plugin dissectors and codecs are inventoried in §2.2.

9.2 Lua scripting

The epan/wslua layer embeds Lua for dissectors, taps, and post-processors without recompiling. Load extra scripts with -X lua_script:<file> (arguments via -X lua_scriptN:<arg>), or drop Lua plugins in the plugin folders. This is the primary supported way to extend dissection at a site without touching C.

9.3 External capture (extcap)

extcap programs appear as capture interfaces (-D). Bundled: androiddump, sshdump, ciscodump, udpdump, randpktdump, sdjournal, dpauxmon, etwdump, wifidump, sshdig. They live in the extcap directory (WIRESHARK_EXTCAP_DIR overrides) and advertise their own config options, which the GUI renders. Because several run remote captures over SSH, treat them as network-touching and audit their use.

9.4 Programmatic / pipeline integration

• sharkd exposes analysis over JSON-RPC for building front-ends/back-ends.
• TShark output formats (-T json|jsonraw|ek|pdml|psml|fields) integrate with downstream tooling — e.g. -T ek produces newline-delimited JSON for Elasticsearch bulk import (mapping from tshark -G elastic-mapping).
• -G glossaries expose the internal registries (fields, protocols, dissector tables, services, manuf) for external tooling to consume.

10. Developer Internals

10.1 Building from source

CMake out-of-tree build:

cmake -S . -B build            # add -DENABLE_ZSTD=OFF etc. to drop optional libs
cmake --build build

Requires Python 3, a C17/C++17 compiler, GLib, GCrypt, and (for the GUI) Qt 6; Perl and GNU flex generate some sources; AsciiDoctor builds docs. See INSTALL, README.linux/README.macos/README.bsd/README.msys2, and the Developer's Guide (doc/wsdg_src/).

10.2 Repository structure

10.3 Module reference (extracted metrics)

Static analysis extracted 203 classes/type-hierarchies and 1,997 functions from the C/C++ core, concentrated in epan (engine), ui/qt (GUI models/widgets), and wiretap (file readers). The single largest unit is epan/dissectors/ (~2,150 files, ~113 MB of source) — each dissector is largely self-contained, registering its protocol, fields, and dissection function with the engine.

Note

Dissector code-generation: many dissectors are generated, not hand-written. tools/asn2wrs.py compiles ASN.1 specifications into dissectors; tools/dissector_generators/ produces others (ETI, nl80211, TLS CT log IDs, SKINNY, MIDI SysEx, sysdig events). When modifying such a protocol, edit the spec/generator, not the generated C. These generators are the source of the Python-tool CLI/error surface (asn2wrs, lex, yacc) rather than the runtime product.

10.4 Code patterns

• Dissector delegation: each dissector consumes its header and hands the remainder to a sub-dissector via dissector tables (tshark -G dissector-tables) keyed on a selector (e.g. tcp.port); "Decode As" and heuristic dissectors extend this.
• Field registration: protocols register typed header fields (hf_), used uniformly by display, filtering, and extraction — one registration drives all three.
• Scoped memory (wmem): allocations are tied to packet/file/capture scope and freed en masse.
• Two-pass analysis: forward-references (response-in-frame, reassembly) require -2.

10.5 Testing Strategy

Tests live in test/ and are Python-driven (pytest-style suites): suite_dfilter (display-filter engine), suite_dissectors (protocol decoding), lua (wslua), plus captured baseline outputs compared against tool output, and captures/keys fixtures. Fuzzing is first-class: fuzz/ and tools/oss-fuzzshark continuously fuzz dissectors, and editcap -E/-o/--seed generate reproducible malformed inputs for dissector fuzz-testing.

11. Troubleshooting

Operator-grade issues. See the User Guide for end-user symptoms; this section focuses on deployment/operations.

Error: You don't have permission to capture on that device

• Cause: The invoking user lacks capture rights; dumpcap is not group-restricted with capabilities, or the user isn't in the capture group.
• Solution: Add the user to wireshark (usermod -aG wireshark <user>); ensure dumpcap has cap_net_raw,cap_net_admin and the right group ownership; on Debian/Ubuntu run dpkg-reconfigure wireshark-common.
• Prevention: Bake the capture-privilege model into your image; never fix it by running as root.

Symptom: capture works as root but not as a normal user, and WIRESHARK_*_DIR overrides are ignored

• Cause: By design, the directory-override env vars are ignored under root/setuid.
• Solution: Run as an unprivileged user with dumpcap capabilities; set the overrides in that context.
• Prevention: Don't run privileged; the isolation model assumes an unprivileged front-end.

Symptom: fleet-wide display/coloring filters don't appear for users

• Cause: Global and personal dfilters/cfilters/colorfilters/dmacros are not merged; a user's personal file suppresses the global one.
• Solution: Deploy defaults as the personal files (or ensure users have none), or use profiles.
• Prevention: Choose global-vs-personal deliberately given the no-merge rule.

Symptom: a protocol you disabled globally can't be re-enabled by users (or vice versa)

• Cause: Protocols listed in the global disabled_protos cannot be enabled by users (intended policy control).
• Solution: If users need it, remove it from the global file and manage per-user instead.
• Prevention: Reserve global disables for true policy; use personal/profile disables for preference.

Symptom: high packet drop rate on a fast link

• Cause: Buffer too small or synchronous name resolution during single-pass/live capture.
• Solution: dumpcap -n -B <large> with a capture filter; analyze offline; add -t (thread per interface) and -C/-N memory bounds.
• Prevention: Standardize a high-rate capture recipe (dumpcap + -n + -B + -f + ring buffer).

Error: compressed capture won't open / feature missing despite install

• Cause: The relevant optional library wasn't compiled into that build (ENABLE_ZLIB/LZ4/ZSTD/SMI/GNUTLS).
• Solution: Check tshark -v; deploy a build with the needed libraries.
• Prevention: Validate the compiled-in feature set as part of image acceptance.

Error: mergecap fails combining files of different encapsulation

• Cause: Mixed link types force WTAP_ENCAP_PER_PACKET, unsupported by pcap output.
• Solution: Output pcapng, or normalize encapsulation first.
• Prevention: Merge like-typed captures; default to pcapng.

Symptom: automated pipeline crashes on a hostile capture

• Cause: A dissector bug hit by malformed/attacker-crafted input.
• Solution: Update Wireshark; run the pipeline sandboxed with a whitelist (--disable-protocol ALL --enable-protocol <needed>); capture crashes for reporting.
• Prevention: Patch promptly, sandbox, minimize enabled dissectors.

Symptom: shared captures leak internal hostnames/keys

• Cause: pcapng NRB/DSB and comments travel with the file.
• Solution: Scrub with editcap --discard-name-resolution --discard-all-secrets --discard-capture-comment --discard-packet-comments.
• Prevention: Add a scrub step to any capture-sharing workflow.

12. Potential Improvements

Observations from the source, offered as forward-looking notes (not defects):

• Dissector attack surface is inherently large (~2,150 dissectors parsing untrusted input). The project's mitigations — continuous fuzzing (fuzz/, oss-fuzzshark), abort-on-bug env switches, and rapid dissector releases — are the right posture; operators should mirror it with prompt patching and sandboxing rather than expecting a "safe mode." Sandboxed/least-privilege dissection remains the highest-value hardening direction.
• SMB SRT statistics note a known simplification in-source: only the first command in an AndX chain is counted (documented as "a flaw that might be fixed in the future"). Consumers of -z smb,srt should account for it.
• Deprecated flags persist for compatibility: dumpcap -n/-P (superseded by -F), and older display-filter unquoted-literal comparisons (deprecated in favor of double-quoted strings, disallowed entirely by matches). Migrate scripts to the current forms.
• Config-file no-merge behavior for filters/macros/colors is a recurring fleet-management footgun (see §4.2); documenting/standardizing on profiles avoids surprises.
• Generated dissectors require editing specs/generators, not the emitted C — a workflow worth enforcing in review to prevent drift between spec and generated output.

13. Quick Reference

Key tools

wireshark (GUI) · tshark (CLI analyzer) · dumpcap (privileged capture) · editcap · mergecap · capinfos · captype · text2pcap · reordercap · randpkt · rawshark · sharkd (JSON-RPC) · dftest · mmdbresolve

Key paths

Diagnostic commands

wireshark -v                       # compiled-in libraries/features
tshark -D                          # list capture interfaces
tshark -G folders                  # resolve every config/data folder
tshark -G defaultprefs             # authoritative preference list
tshark -G plugins                  # loaded plugins
tshark -G protocols                # registered protocols
dumpcap -S -i eth0                 # per-second capture stats
capinfos <file>                    # capture-file metadata

Hardening checklist

• [ ] Capture rights on dumpcap only (capabilities/group); GUI/TShark never root or setuid.
• [ ] Wireshark kept patched (dissector CVEs) across the fleet.
• [ ] Untrusted captures analyzed sandboxed/offline; unneeded dissectors disabled (global disabled_protos / --only-protocols).
• [ ] Capture files treated as sensitive; secrets/NRB/comments scrubbed before sharing (editcap --discard-*).
• [ ] rpcap:// remote capture and SSH extcap tools audited/restricted; sharkd never network-exposed.
• [ ] Fleet config standardized via global directory + profiles (mind the filter/macro no-merge rule).

Build feature toggles

-DENABLE_ZLIB=OFF · -DENABLE_LZ4=OFF · -DENABLE_ZSTD=OFF · -DENABLE_SMI=OFF · -DENABLE_GNUTLS=… · -DENABLE_PCAP=… (validate the result with tshark -v).