Wireshark Cards

This deck introduces the fundamentals of Wireshark, the widely used network protocol analyzer. The cards walk you through what Wireshark is, the difference between capture filters and display filters, the syntax for filtering by IP addresses, ports, protocols like HTTP and DNS, MAC addresses, and specific text strings. You'll also review logical operators, promiscuous mode, the libraries Wireshark relies on for packet capturing, and features like TCP stream reconstruction that help you follow an entire conversation between two hosts.

It's a great fit for networking students, IT professionals, cybersecurity beginners, or anyone preparing for a certification that touches on packet analysis. If you're new to traffic capture, these cards give you a solid foundation in the vocabulary and core features before you dive into more advanced dissections.

To get the most out of your study sessions, try opening Wireshark alongside the deck and practicing each filter or concept on a real capture file as you go. Spacing your reviews over several days, rather than cramming, will help the syntax and operator differences stick in your memory. Focus extra attention on the contrast between capture and display filters, since that distinction is one of the most common stumbling blocks for beginners.

Wireshark is a widely used network protocol analyzer designed for troubleshooting, protocol development, education, and detailed inspection of network traffic. It captures packets from a live network interface or reads them from a saved capture file, then decodes the raw bytes into structured protocol layers that a human can read. Under the hood, Wireshark relies on platform-specific capture libraries: on Linux and Unix systems it uses libpcap, while on Windows it uses Npcap (the modern successor to the older WinPcap). Because these libraries sit between the network card and the application, they enable features like promiscuous mode, which instructs the network interface to capture every frame on the segment, not just those addressed to the capture host.

One of the most important conceptual distinctions in Wireshark is the difference between capture filters and display filters. Capture filters use Berkeley Packet Filter (BPF) syntax and are applied before packets are written to disk, so they limit what is recorded at all; this is useful for keeping capture files small on busy links. Display filters, by contrast, use Wireshark's own rich expression language and are applied after capture to narrow what is visible on screen without dropping any data. A simple address filter such as host 192.168.1.1 written in BPF is written as ip.addr == 192.168.1.1 in Wireshark's display syntax, illustrating the different conventions.

Display filter expressions can be combined using logical operators. Wireshark accepts either symbolic forms (&&, ||, !) or word forms (and, or, not), and parentheses can be used to group conditions for complex queries like (ip.addr == 192.168.1.1 && tcp.port == 80) || (ip.addr == 192.168.1.2 && tcp.port == 443). Comparisons can target addresses, ports, lengths, flags, and many other fields; for example, tcp.port == 80 narrows the view to a specific service, while frame.len > 1000 highlights larger-than-average frames. Searches inside payload data are supported with frame contains "search_string", which is especially handy when hunting for a known token in unencrypted traffic.

Almost every protocol Wireshark can dissect has a short, intuitive filter name. The core transport and network protocols use just their names: tcp, udp, icmp, arp, ip, and ipv6 all work directly. Application-layer protocols are similarly concise, with filters such as http, tls, dns, dhcp, smtp, pop3, imap, ftp, ssh, snmp, ntp, smb, and ldap. Newer or specialized protocols like http2, quic, websocket, sip, rtp, rtcp, kerberos, nfs, and iscsi each have their own dedicated filters, making it easy to isolate a single service in a mixed capture.

Address-based filtering follows predictable field naming. For IPv4 traffic, ip.addr matches either source or destination, while ip.src and ip.dst restrict to a single direction; the equivalent for Ethernet is eth.addr, eth.src, and eth.dst, and for IPv6 it is ipv6.addr, ipv6.src, and ipv6.dst. VLAN, MPLS, and tunneling protocols are accessible through filters such as vlan.id, mpls.label, vxlan, and geneve, which are invaluable when analyzing enterprise or service-provider networks. Specific IP protocol numbers can also be targeted directly, for example ip.proto == 6 for TCP and ip.proto == 17 for UDP, allowing precise matching without relying on the higher-level protocol dissectors.

Port-based filtering is just as flexible. tcp.port and udp.port match either end of a conversation, while tcp.srcport, tcp.dstport, udp.srcport, and udp.dstport narrow to one side. Common service filters therefore reduce to expressions like tcp.port == 80, udp.port == 53, or sip on its standard port 5060. When a non-standard port is in use, combining a port filter with a protocol dissector via the Decode As feature lets Wireshark reinterpret traffic correctly, after which the usual protocol filters apply as expected.

Because TCP is connection-oriented and stateful, much of Wireshark's analytical power is devoted to inspecting TCP behavior. The six control flags — SYN, ACK, FIN, RST, PSH, and URG — can be tested individually with fields like tcp.flags.syn == 1, tcp.flags.ack == 1, tcp.flags.fin == 1, tcp.flags.rst == 1, tcp.flags.psh == 1, and tcp.flags.urg == 1. Classic connection lifecycle events fall out naturally: a SYN with no ACK (tcp.flags.syn == 1 && tcp.flags.ack == 0) marks a connection initiation, a SYN-ACK (both flags set) marks the server's response, and a FIN (with or without ACK) marks teardown. A complete three-way handshake can therefore be expressed as a single filter combining those three flag combinations.

Wireshark's TCP analysis engine produces a rich set of expert annotations that help diagnose performance and reliability problems. Filters such as tcp.analysis.retransmission, tcp.analysis.fast_retransmission, tcp.analysis.spurious_retransmission, tcp.analysis.duplicate_ack, tcp.analysis.out_of_order, and tcp.analysis.lost_segment expose the symptoms of packet loss, network reordering, and congestion. Flow control issues appear as tcp.analysis.zero_window (the receiver's buffer is full), tcp.window_size == 0, and tcp.analysis.window_update. Keep-alive traffic shows up as tcp.analysis.keep_alive and tcp.analysis.keep_alive_ack, which are useful for distinguishing idle but healthy connections from dead ones.

Beyond flags and analysis events, Wireshark exposes the deeper fields of the TCP header. Sequence and acknowledgment numbers are available as tcp.seq and tcp.ack, the urgent pointer as tcp.urgent_pointer, and the window size as tcp.window_size, which can be combined with relational operators to spot flow-control problems (for example tcp.window_size < 1000). TCP options have their own filter fields, including tcp.options.mss_val, tcp.options.wscale_val, tcp.options.sack_perm, tcp.options.sack, tcp.options.timestamp.tsval, and tcp.options.nop, allowing targeted inspection of negotiated features. A reconstructed view of an entire conversation is available through the Follow TCP Stream feature, which reassembles the application data exchanged between two endpoints into a readable stream.

HTTP filtering is one of the most common tasks in Wireshark, and the http filter alone captures every HTTP packet. Requests can be narrowed further by method using http.request.method, with values like "GET", "POST", "PUT", "DELETE", "HEAD", "OPTIONS", "PATCH", "TRACE", and "CONNECT" corresponding to the standard HTTP verbs. Response status codes are tested with http.response.code, enabling filters such as http.response.code == 404 for missing resources, http.response.code == 401 for authentication challenges, http.response.code == 407 for proxy authentication, http.response.code == 200 for successful responses, and http.response.code >= 500 to surface any server-side error. Ranges like http.response.code >= 300 && http.response.code < 400 reveal redirects.

HTTP headers and metadata are also filterable. Common expressions include http.host == "example.com" to find requests aimed at a particular site, http.request.uri contains "/api/" to isolate API traffic, http.user_agent contains "Chrome" to identify a specific browser, and http.user_agent matches "(bot|crawler|scanner)" to flag automated clients. Content negotiation is visible through http.content_type, which can be combined with contains "json" or contains "xml" to isolate REST or SOAP traffic, while http.content_encoding == "gzip" identifies compressed responses. Other useful headers include http.cookie, http.set_cookie, http.authorization, http.transfer_encoding, http.cache_control, http.etag, and http.last_modified. For connection behavior, http.connection == "keep-alive" identifies HTTP/1.1 persistent connections, while http.connection == "close" marks non-persistent ones.

DNS filters operate at several layers of detail. The bare dns filter matches any DNS packet, while dns.flags.response == 0 isolates queries and dns.flags.response == 1 isolates replies. Specific query types are selected with dns.qry.type, including 1 for A records, 28 for AAAA (IPv6), 15 for MX, 12 for PTR (reverse lookups), 5 for CNAME, and 16 for TXT. A specific name can be matched with dns.qry.name == "example.com" or via a regex such as dns.qry.name contains "example.com". Response codes are checked with dns.flags.rcode, where 0 is NOERROR, 3 is NXDOMAIN, and 2 is SERVFAIL. Flags like dns.flags.authoritative, dns.flags.recdesired, dns.flags.recavail, dns.flags.truncated, dns.flags.authentic, and dns.flags.checkdisable describe the behavior negotiated between client and server. DHCP filters rely on bootp.option.type == 53 combined with a numeric value, producing messages for Discover (1), Offer (2), Request (3), Decline (4), ACK (5), NAK (6), Release (7), and Inform (8). Other protocol families follow the same pattern: TLS uses fields like tls.handshake.type (1 for Client Hello, 2 for Server Hello, 11 for Certificate, 20 for Finished) and tls.record.content_type (22 for handshake, 21 for Alert, 23 for application data); ICMPv6 uses icmpv6.type (133 for Router Solicitation, 134 for Router Advertisement, 135 for Neighbor Solicitation, 136 for Neighbor Advertisement, 128/129 for echo request/reply); and SIP uses sip.Method and sip.Status-Code to match specific requests and responses.

Beyond individual packet filters, Wireshark provides a Statistics menu full of tools that summarize entire captures. The Protocol Hierarchy view (Statistics > Protocol Hierarchy) shows a tree of every protocol found in the capture along with packet counts, byte counts, and percentages, which is a quick way to see which protocols dominate a trace. The Conversations window (Statistics > Conversations) lists every distinct conversation between two endpoints, broken down by Ethernet, IPv4, IPv6, TCP, UDP, and other protocols, and is invaluable for spotting heavy talkers. The related Endpoints window (Statistics > Endpoints) shows traffic aggregated per host, again segmented by layer.

Time-based analysis is supported by the I/O Graph (Statistics > I/O Graph) and the Flow Graph (Statistics > Flow Graph). The I/O Graph plots packet rate or byte rate over time on a configurable Y-axis, making it easy to visualize throughput, bursts, and gaps, and to compare multiple filters on the same timeline. The Flow Graph renders a directional picture of packet exchange between hosts, which is particularly helpful when reasoning about connection patterns. Service Response Time (Statistics > Service Response Time) measures the delay between request and reply for protocols like HTTP, SMB, and LDAP, while the Packet Lengths statistics (Statistics > Packet Lengths) histogram the distribution of frame sizes to surface MTU-related issues.

The Expert System provides an automated health check on a capture. By examining protocol behavior, it tags packets as Chat, Note, Warning, or Error, with these categories also accessible through filters like expert.message == "Warning" or expert.severity == 3. Typical warnings include Duplicate ACK, Fast Retransmission, Out-of-Order Segment, Previous Segment Not Captured, Spurious Retransmission, Zero Window, Window Update, Keep-Alive, Connection Reset, and Malformed Packet. The Expert Info window (Analyze > Expert Info) consolidates these into a single review pane, while statistics like Protocol Hierarchy, Conversations, and Endpoints complement it with quantitative summaries. The Summary window (Statistics > Capture File Properties) gives a one-glance view of the capture's size, duration, packet count, and interface details.

Before capturing, the Capture > Options dialog controls how the trace is collected. The interface list shows every available network adapter, and the chosen interface determines which traffic can be observed. Promiscuous mode can be enabled there, instructing the driver to deliver every frame seen on the wire, not just those destined for the local host. Capture filters entered in this dialog use BPF syntax, with keywords like host, src host, dst host, port, src port, dst port, net, tcp, udp, and icmp allowing precise pre-capture narrowing. Examples include host 192.168.1.1, src host 192.168.1.1, dst port 80, and net 192.168.1.0/24.

Several other capture options affect how data is stored. The snapshot length limits how many bytes of each frame are recorded, which is useful for header-only captures on high-volume links; the default of 65535 bytes captures full packets but can be reduced to shrink files. A ring buffer can be enabled to rotate through a fixed number of files, preventing disk exhaustion on long-running captures, and automatic stop conditions let a capture end after a specified number of packets, files, or elapsed time. The output file format is pcapng by default, though the older pcap format is still supported; pcapng adds metadata, multiple interfaces, and better support for modern features compared to pcap.

After capture, files can be exported in several formats. File > Export Specified Packets writes the currently visible (or marked) packets, while File > Export Packet Dissections produces structured representations such as CSV, JSON, PDML, and PSML, each of which is suited to a different downstream tool. File > Export Packet Bytes saves raw payload, and File > Export Objects allows extraction of files transferred over protocols like HTTP, SMB, or DICOM. The Statistics > Resolved Addresses view lists name-resolution results for IPs, MACs, and ports when those features are enabled through View > Name Resolution.

Wireshark ships with a family of command-line companions that support scripted and remote workflows. TShark is the CLI counterpart to the GUI, capable of capturing with tshark -i eth0 -w output.pcapng, reading files with tshark -r input.pcapng, applying display filters via -Y, and emitting selected fields with -T fields -e ip.src -e ip.dst. Dumpcap is the lower-level capture engine used by both Wireshark and TShark, and it accepts the same kinds of options, including -b filesize for ring-buffer-style file rotation. Mergecap combines several capture files into one with mergecap -w merged.pcapng file1.pcap file2.pcap, and Editcap edits existing files, supporting tasks like splitting every 1000 packets with editcap -c 1000 input.pcapng output.pcapng, deduplicating with -d, and other transformations.

Additional utilities round out the toolkit. Reordercap sorts a capture's packets by timestamp, which is useful when merging logs from sources with skewed clocks. Text2pcap converts a hex-dump text file into a pcap capture file, allowing users to construct traces from logs or documentation. Capinfos reports metadata about a capture file, including its format, size, duration, and packet counts, which is helpful for quickly summarizing a large corpus of files.

These tools combine into practical workflows for many common tasks. Troubleshooting slow network performance often starts with an I/O Graph and the Round Trip Time TCP Stream Graph, followed by filters for retransmissions and zero windows. DNS issues can be investigated by filtering dns and checking for NXDOMAIN responses, while HTTP problems are typically isolated with http.response.code >= 400 and inspected request by request. TLS handshake failures are diagnosed by inspecting tls.handshake and the Alert records. Security investigations rely on patterns like tcp.flags.syn == 1 && tcp.flags.ack == 0 for SYN floods, ip.flags.mf == 1 && ip.frag_offset > 0 for fragmented traffic, http.authorization for exposed credentials, and dns.qry.name matches for suspicious domain patterns, with Conversations and I/O Graphs providing the high-level summaries that tie individual packets into a coherent narrative.