Course companion for: NET-101 (primary) + NET-201 + ADV-101 + RE-101 (secondary cross-references)
Scope: pcap walkthrough; pairs with the curated catalog manifest
Pairs with manifest: pcap-tools/fixtures/curated-12-manifest.json (entries net-101-fund-*)
Catalog surface: https://virtuscyberacademy.org/pcap-tools/
Version: 2026-05-07 v1
Overview
This handout is the companion walkthrough for six academy-original fundamentals PCAPs synthesized via scapy and added to the curated catalog under the NET-101 track. The pedagogical goal is vocabulary-fluency for protocol byte-shape recognition before students touch malformed-record CVE captures: a NET-101 student opening the canonical DNS query capture, walking the layer stack down from Ethernet to UDP to DNS, and naming the bytes at each layer is then prepared to read the Wireshark RCE Quartet's malformed TLS / SBC / RDP / Profile-import captures with the right vocabulary already installed. The handout assumes no prior packet-analysis experience; it does assume FND-102 Python fluency for students who want to extend the synthesis-via-scapy pattern beyond the academy-shipped corpus.
The six captures are academy-original, synthesized on the operator laptop via scapy 2.7.0 with explicit byte-shape control at every layer. License is academy-original. No live-capture noise; no PII risk; no third-party-traffic concerns. Each capture passed a tshark display-filter sanity check before commit (verification command set documented in §3 per capture). The captures pair with the catalog-page selector at https://virtuscyberacademy.org/pcap-tools/ and render as click-to-load entries against the in-browser Wireshark / tshark Wasm workbench.
--authorized-by discipline applies even though these captures are academy-synthesized. The captures and the analysis discipline they teach extend to academy-owned, intentionally-vulnerable lab harnesses inside the fwlab container or equivalent. Production network captures, third-party traffic, and any traffic carrying real-user PII are out of scope for the discipline this handout teaches; SOC analysts inheriting the academy's pattern apply it under their own organizational authorization.
§1: What this handout covers
Six academy-original fundamentals PCAPs covering the canonical traffic samples a NET-101 graduate must recognize at byte-shape register: DNS query/response; HTTP GET full cycle with TCP teardown; bare TCP three-way handshake; ICMP echo request and reply; ARP request and reply; DHCP four-step handshake. Each capture is small (under 2 KB), every byte is intentional, and the canonical Wireshark display filter that finds the distinctive packets is documented per capture.
The pedagogical thesis is that vocabulary-fluency precedes anomaly recognition. A student who has walked the layer stack of a known-clean DNS query has the byte-shape vocabulary to read a malformed DNS query as a deviation from the clean baseline; a student who has seen the canonical TCP three-way handshake recognizes a half-open scan or a SYN-flood as a deviation from the baseline. The Wireshark CVE Quartet's malformed-record captures (TLS dissector ECH integer truncation, SBC Codec frame-count overflow, RDP ZGFX missing bounds-check, Profile-import zip-slip) are best read after the baseline; this handout supplies the baseline.
The captures deliberately use IPv4 + classical protocols (DNS, HTTP/1.1 plain, TCP, ICMP, ARP, DHCP) rather than IPv6 + modern protocols (HTTP/2, HTTP/3, QUIC, TLS 1.3 + ECH, mDNS, SSDP). The classical-baseline scope reflects NET-101's pedagogical commitment to teach the substrate that every modern protocol layers on; IPv6 fundamentals, HTTP/2 fundamentals, and TLS 1.3 fundamentals are named as future-related topics in §6.3.
§2: The catalog at a glance
| File | Protocols | Size | Canonical display filter | Pedagogical anchor |
|---|---|---|---|---|
fundamentals-dns-query.pcap |
DNS over UDP/53 | 225 B | dns.qry.name == "example.com" |
Resolver request + response pair; DNS message format |
fundamentals-http-get.pcap |
HTTP/1.1 over TCP/80 | 958 B | http.request.method == "GET" |
Full HTTP cycle with TCP three-way and FIN/ACK teardown |
fundamentals-tcp-3way.pcap |
TCP/22 (SSH port; no payload) | 242 B | tcp.flags.syn == 1 |
TCP connection establishment in isolation |
fundamentals-icmp-ping.pcap |
ICMP echo | 216 B | icmp.type == 8 (request); icmp.type == 0 (reply) |
Simplest IP-layer probe |
fundamentals-arp-request-reply.pcap |
ARP on faux Ethernet | 140 B | arp.opcode == 1 (request); arp.opcode == 2 (reply) |
Layer-2 address resolution |
fundamentals-dhcp-handshake.pcap |
DHCP / BOOTP over UDP/67-68 | 1299 B | dhcp.option.dhcp |
Four-step lease acquisition |
Total corpus size: 3080 bytes across six captures. Cumulative is well under the 100 KB ceiling stated in the brief; each individual capture is under 2 KB.
The captures use 02:00:00:* MAC addresses (locally-administered unicast range; no real-vendor collision) and 192.0.2.0/24 IPv4 addresses (TEST-NET-1; reserved for documentation per RFC 5737). The DNS query targets example.com (canonical IETF-blessed documentation domain) and the response carries the legitimate IPv4 address 93.184.216.34. No real-user PII appears in any capture; no real-network traffic is recorded; no live-capture fingerprints are present.
§3: Per-capture walkthrough
§3.1 fundamentals-dns-query.pcap
§3.1.1 What the capture contains. Two packets: a single DNS A-record query for example.com. from a documentation client at 192.0.2.10 to a documentation resolver at 198.51.100.53, and the matching A-record response. Transaction ID is 0x1234; the response carries the legitimate example.com IPv4 address 93.184.216.34.
§3.1.2 Why it matters. DNS is the first protocol most students learn end-to-end because it is small, common, and architecturally illustrative. A NET-101 graduate who walks this capture's two packets understands the DNS message format (transaction ID + flags + counts + question section + answer section), the request-response pairing pattern (matching transaction ID), and the canonical resolver behavior. The same byte shapes appear in every DNS capture the student will read for the rest of their career; this two-packet capture installs the vocabulary.
§3.1.3 Canonical display filter. dns.qry.name == "example.com" matches both packets (verified via tshark -r fundamentals-dns-query.pcap -Y 'dns.qry.name == "example.com"' | wc -l returning 2). The filter teaches Wireshark's protocol-field-comparison syntax; the same shape generalizes to any DNS field (dns.flags.response, dns.qry.type, dns.resp.ttl, dns.a).
§3.1.4 Layer-stack walkthrough. Ethernet header (14 bytes; locally-administered MACs at both ends) → IPv4 header (20 bytes; TEST-NET-1 source; 198.51.100.53 destination; protocol field 0x11 = UDP) → UDP header (8 bytes; ephemeral source port 51234; destination port 53) → DNS payload (query: 12-byte header + question section; response: 12-byte header + question section + answer section with 4-byte A-record rdata).
§3.1.5 What to look at next. fundamentals-tcp-3way.pcap for the connection-oriented analog (DNS over UDP is connectionless; HTTP over TCP requires a three-way handshake first). The Wireshark CVE Quartet's TLS dissector capture (cve-2026-5402-tls-ech.pcap per the parent quartet handout) reads against this baseline as a malformed-record extension of the same layer stack.
§3.2 fundamentals-http-get.pcap
§3.2.1 What the capture contains. Ten packets: the full HTTP/1.1 GET cycle from documentation client 192.0.2.10:49152 to documentation server 93.184.216.34:80. The cycle covers the TCP three-way handshake (SYN, SYN-ACK, ACK), the GET request with canonical headers (Host, User-Agent: virtus-academy-fundamentals/1.0, Accept, Connection: close), the server's ACK of the request, the 200 OK response with a small text body, the client's ACK of the response, the server's FIN/ACK, the client's FIN/ACK, and the server's final ACK. Sequence and acknowledgment numbers form a valid TCP exchange throughout.
§3.2.2 Why it matters. HTTP/1.1 is the protocol every web-related capture references implicitly; HTTP/2 + HTTP/3 + QUIC all build on the conceptual model HTTP/1.1 establishes (request + response + headers + body). A NET-101 graduate who walks this capture has the application-layer vocabulary (request line, status line, headers, body, content-length, connection control) plus the transport-layer vocabulary (sequence numbers, acknowledgments, window sizes, FIN/ACK teardown) installed. The walkthrough is also the academy's first exposure to TCP sequence-number arithmetic at depth: the SYN consumes one sequence number; subsequent ACKs name prev_seq + payload_length; the FIN consumes one sequence number on each side of the teardown.
§3.2.3 Canonical display filter. http.request.method == "GET" matches exactly one packet (the GET request itself). Complementary filters: http.response.code == 200 (matches the response packet); tcp.flags.fin == 1 (matches both FIN-bearing packets). The HTTP filters work because Wireshark's HTTP dissector parses the application layer; students should know that the dissector requires the underlying TCP stream to reassemble cleanly, which the canonical capture guarantees.
§3.2.4 Layer-stack walkthrough. Ethernet → IPv4 → TCP (with timestamp options omitted for clarity; window scaling option absent for the same reason) → HTTP. The HTTP layer carries CR-LF terminated lines and a blank line separating headers from body. A student inspecting the capture in Wireshark should expand the TCP header to see the SEQ / ACK arithmetic and expand the HTTP header to see the request method, URI, version, headers, and body.
§3.2.5 What to look at next. fundamentals-tcp-3way.pcap to see the three-way handshake in isolation (without HTTP application payload obscuring the TCP semantics). The cross-chapter NET-101 anchor reading guide (cross-chapter-net-101-anchor-reading-guide.md) carries Stevens TCP/IP Illustrated Vol 1 Chapter 7 as the canonical TCP-three-way-handshake reading.
§3.3 fundamentals-tcp-3way.pcap
§3.3.1 What the capture contains. Three packets: SYN (client 192.0.2.10:49200 → server 192.0.2.20:22), SYN-ACK (server → client), ACK (client → server). No application payload; no teardown; the connection is established and the capture ends. Initial client sequence number is 0xa1b2c3d4; initial server sequence number is 0x55667788; both increment by 1 on the SYN-and-ACK exchange.
§3.3.2 Why it matters. The TCP three-way handshake is the canonical connection-establishment pattern that every reliable-stream protocol on top of TCP inherits. Isolating the handshake (no payload) lets students see the TCP semantics in their pure form: SYN flag bits, MSS option negotiation in SYN and SYN-ACK, sequence-number selection at each end, the ACK number convention (prev_peer_seq + 1). The same shape recurs in every TCP capture; this three-packet capture installs the vocabulary cleanly.
§3.3.3 Canonical display filter. tcp.flags.syn == 1 matches two packets (SYN and SYN-ACK; both have the SYN flag set). Complementary: tcp.flags.ack == 1 and tcp.flags.syn == 0 matches the third packet (the bare ACK that completes the three-way). Students should know that Wireshark's TCP dissector exposes individual flag bits as separate filter fields, which lets the analyst combine flag matches with logical operators.
§3.3.4 Layer-stack walkthrough. Ethernet (14 bytes; client and server MACs in the documentation range) → IPv4 (20 bytes; TEST-NET-1 source and destination) → TCP (20-byte header + 4-byte MSS option in SYN and SYN-ACK; no options in the bare ACK). The TCP option field carries the Maximum Segment Size negotiation; both ends advertise 1460 bytes, which is the canonical Ethernet-over-IPv4 MSS (1500-byte MTU minus 20-byte IP header minus 20-byte TCP header).
§3.3.5 What to look at next. fundamentals-http-get.pcap for the same three-way handshake followed by HTTP application payload and FIN/ACK teardown. NET-101 Lab 4 reproduces this capture against a lab harness using tcpdump -i lo port 22 -w lab-tcp.pcap followed by an nc -lp 22 and nc 127.0.0.1 22 pair on the same host.
§3.4 fundamentals-icmp-ping.pcap
§3.4.1 What the capture contains. Two packets: an ICMP echo request (type 8) from 192.0.2.10 to 192.0.2.1, and the matching echo reply (type 0). Identifier 0xbeef and sequence number 1 are shared between the request and the reply, which is how ICMP pairs request with reply. The payload academy-fundamentals-icmp-ping-payload is identical in both packets, mirroring the canonical ping behavior where the requester sends a payload and the responder echoes it back.
§3.4.2 Why it matters. ICMP is the simplest IP-layer probe and the canonical "is the host alive and routable" diagnostic. A NET-101 graduate walking this capture sees the IP layer in its purest form (no transport layer; ICMP rides directly on IP) and learns the request-response pairing pattern at a layer below TCP. The same byte shape appears in every traceroute capture, every ping diagnostic, and every ICMP-based covert-channel research write-up.
§3.4.3 Canonical display filter. icmp.type == 8 matches the echo request; icmp.type == 0 matches the echo reply. Complementary: icmp.ident == 0xbeef matches both packets via the shared identifier (which is how a pcap of mixed ping conversations distinguishes which reply pairs with which request). The filter teaches that ICMP types are numeric and well-known; the canonical Wireshark display shows the type symbolically (Echo (ping) request, Echo (ping) reply) but the underlying byte is the integer.
§3.4.4 Layer-stack walkthrough. Ethernet → IPv4 → ICMP. The ICMP header is 8 bytes (type, code, checksum, identifier, sequence) followed by the payload. There is no transport layer; the IPv4 protocol field carries 0x01 (ICMP) directly. The payload is arbitrary bytes that the responder echoes; this capture's payload is a deliberate ASCII string for legibility.
§3.4.5 What to look at next. fundamentals-tcp-3way.pcap for the contrast between ICMP's stateless request-reply and TCP's stateful connection establishment. NET-201 Module 6 covers ICMP-based diagnostics at deeper register including traceroute mechanics and the asymmetric-path detection patterns that operational network engineers use daily.
§3.5 fundamentals-arp-request-reply.pcap
§3.5.1 What the capture contains. Two packets at layer 2 (Ethernet) without IP layer: an ARP request from 02:00:00:00:00:01 (broadcasting "who has 192.0.2.1?") and the ARP reply from 02:00:00:00:00:fe (claiming the IP belongs to its own MAC). The reply unicasts back to the requester; the request broadcasts to ff:ff:ff:ff:ff:ff. ARP opcodes are 1 for request and 2 for reply.
§3.5.2 Why it matters. ARP is the protocol that binds layer-3 IPv4 addresses to layer-2 Ethernet MAC addresses. Every IPv4-over-Ethernet conversation requires an ARP exchange to resolve the destination MAC for the next-hop IP address; without ARP, the packet has nowhere to go on the local segment. A NET-101 graduate who walks this capture understands the protocol's stateless-broadcast-and-cached-reply pattern and recognizes that the ARP cache (visible via ip neighbor on Linux or arp -a on Windows) is per-host state populated by exactly this protocol.
§3.5.3 Canonical display filter. arp.opcode == 1 matches the request; arp.opcode == 2 matches the reply. Complementary: arp.src.hw_mac == 02:00:00:00:00:01 matches the request (filtered by source MAC); arp.dst.proto_ipv4 == 192.0.2.1 matches the request (filtered by target IPv4). ARP attack analysis (cache poisoning, gratuitous ARP, ARP spoofing) builds on these primitives; PEN-101 Week 9's lateral-movement module exercises the cache-poisoning pattern against an academy lab harness under --authorized-by discipline.
§3.5.4 Layer-stack walkthrough. Ethernet (14 bytes; broadcast destination on the request, unicast destination on the reply; EtherType 0x0806 = ARP) → ARP (28 bytes for IPv4-over-Ethernet; hardware type, protocol type, hardware address length, protocol address length, opcode, sender hardware address, sender protocol address, target hardware address, target protocol address). There is no IP layer; ARP rides directly on Ethernet.
§3.5.5 What to look at next. fundamentals-dhcp-handshake.pcap for the layer-2-broadcast pattern at higher protocol depth (DHCP also broadcasts on the local segment, but at UDP/IP layer rather than at ARP layer). The cross-chapter cross-chapter-cve-class-vocabulary-reference.md does not currently cover ARP-cache-poisoning as a CVE class; the class is operationally important and earns a future related topic per §6.3.
§3.6 fundamentals-dhcp-handshake.pcap
§3.6.1 What the capture contains. Four packets covering the canonical DHCP four-step lease acquisition: DISCOVER (client 0.0.0.0 broadcasting from UDP/68 to UDP/67), OFFER (server 192.0.2.1 broadcasting back with 192.0.2.50 offered), REQUEST (client formally requesting the offered IP), ACK (server confirming the lease). Transaction ID 0x12345678 is shared across all four packets; the BOOTP layer carries the chaddr (client hardware address) and the DHCP options layer carries message-type plus the canonical lease parameters (server identifier, lease time, subnet mask, router).
§3.6.2 Why it matters. DHCP is the protocol that lets a host with no IP configuration (just a MAC address) discover an IP address, subnet mask, gateway, and DNS resolver from a server on the local segment. Every laptop, phone, and IoT device on every network the student will ever touch acquired its IP via DHCP. The four-step pattern (DISCOVER, OFFER, REQUEST, ACK) is canonical; understanding it lets the analyst diagnose connectivity failures (no DHCP server present; server offering lease but client not requesting; ACK not arriving) at the protocol layer.
§3.6.3 Canonical display filter. dhcp.option.dhcp matches all four packets (each carries the DHCP message-type option). Complementary, per-step: dhcp.option.dhcp_message_type == 1 (DISCOVER), == 2 (OFFER), == 3 (REQUEST), == 5 (ACK). The numeric message-type values are part of the DHCP options registry; students should recognize the canonical four (1, 2, 3, 5) plus the operationally-relevant NAK (6) and RELEASE (7).
§3.6.4 Layer-stack walkthrough. Ethernet (broadcast destination on every packet because the client has no IP yet on DISCOVER and REQUEST; broadcast destination on OFFER and ACK because the broadcast-flag in BOOTP forces broadcast even when the server could unicast) → IPv4 (0.0.0.0 source on client packets; 255.255.255.255 destination on every packet) → UDP (port 67 server-side; port 68 client-side) → BOOTP (236-byte fixed header carrying client hardware address) → DHCP (variable-length options field; dhcp_message_type is option 53; server_id is option 54; lease_time is option 51; subnet_mask is option 1; router is option 3; end is option 255).
§3.6.5 What to look at next. fundamentals-dns-query.pcap is what typically happens immediately after DHCP completes (the newly-configured client's first action is usually a DNS query). NET-201's network-architecture module covers DHCP relay agents, DHCP option 82, and DHCP-snooping defensive patterns at deeper register.
§4: Cross-track linkage
| Course | Pickup module / week | Treatment of the fundamentals corpus |
|---|---|---|
| NET-101 | Lab 4 (Wireshark capture and analysis); Lab 5 (Vulnerability identification at protocol layer) | Primary use; students walk every capture in Lab 4 with the catalog selector + the Wasm Wireshark workbench; Lab 5 contrasts the malformed-record CVE Quartet captures against these baselines |
| NET-201 | Network architecture module; NSM-lite Suricata + Zeek authoring | Baseline-anchor for "what does normal look like" discussions; the captures appear in NSM-rule-tuning labs where false-positive avoidance against legitimate baseline traffic is the discipline |
| ADV-101 | CVE-to-tool work where the target is a network protocol | The fundamentals corpus is the contrast set for the CVE captures; ADV-101 students reproduce the malformed-record patterns against academy lab harnesses and validate against the baseline via display-filter comparison |
| RE-101 | Module 7 (CVE class reading list); SB6141 firmware-extraction context | The fundamentals corpus is the byte-shape reference for protocol parsers students reverse-engineer in extracted firmware; the SB6141 lab target's web-management UI captures (when synthesized for a future round) read against these baselines |
The cross-track interleave reflects the academy's discipline that canonical baseline captures appear at multiple registers: NET-101 vocabulary, NET-201 NSM-rule-tuning register, ADV-101 contrast-set register, RE-101 byte-shape-reference register. The same six captures, four registers, four pedagogical purposes; the academy's coordinated curriculum makes the multi-register treatment tractable without each course curating its own baseline corpus.
§5: --authorized-by discipline reminder
These six PCAPs are academy-synthesized via scapy on the operator laptop. Every byte was produced under the academy's authorization and carries the academy-original license. No live network capture; no third-party traffic; no PII. The captures are safe to redistribute, embed in lab harnesses, and use as training material; the academy's catalog-page deployment serves them as click-to-load entries against the in-browser Wasm Wireshark workbench.
The discipline that travels with the captures is the same --authorized-by discipline that PEN-101 Lab 1 establishes and that ADV-101 capstone work enforces. Students learning to capture their own traffic via tcpdump or wireshark operate against academy-owned, intentionally-vulnerable lab harnesses inside the fwlab container or equivalent; production network captures, third-party traffic, and any traffic carrying real-user PII are out of scope for the discipline. Synthesizing additional fundamentals captures via scapy (the related topics in §6.3) is encouraged for cohorts that want to extend the corpus; the synthesis pattern established here generalizes across protocols, and the operator's laptop running scapy is the canonical academy-authorized synthesis surface.