NET-101 Instructor Guide

For instructors and homeschool parents running NET-101. The course is self-runnable from the student-facing materials; this guide adds pacing context, common stumbling blocks, and grading guidance.

Course shape at a glance

Cohort pacing recommendations

• Self-paced (one student): 12 calendar weeks is comfortable. Students with prior networking background may move faster through weeks 1-3.
• Homeschool (1-3 students): 12 weeks at one module per week. Lab work is well-suited to side-by-side sessions with pcap-tools open on a shared screen.
• Classroom (10+ students): 12-14 weeks. Lab weeks 5-6 and 10-11 are the most demanding; plan for extended lab sessions or carry-over to the following week.
• Intensive (full-time, ~2.5 weeks): 132 hours fits in 18 working days at ~7 hours/day.

Per-week pacing notes and common stumbling blocks

Week 1: What is a network?

Pacing: The OSI/TCP/IP section is conceptual and goes quickly. Spend more time on the pcap-tools first contact: many students have never seen a packet capture before and need help understanding that the bytes they see in the hex pane are the actual data on the wire.

Common blocks:

• "The layers feel abstract." Solve by loading a concrete capture immediately (Week 1 uses smoke-tcp-syn-dns.pcap) and pointing at specific bytes: "This is the Ethernet header. These 6 bytes are the destination MAC. These next 6 bytes are the source MAC." Concreteness first.
• Students confuse OSI and TCP/IP layer numbering. For the rest of the course, use TCP/IP layer names (Link, Internet, Transport, Application) rather than OSI numbers to avoid confusion.

Week 2: Ethernet and ARP

Pacing: The ARP field walkthrough is the core exercise; plan 45 minutes for the lab.

Common blocks:

• Students write the ARP reply's target hardware address as the learned MAC address, but in the REQUEST it is 00:00:00:00:00:00 (unknown). Clarify: the request says "I don't know the MAC -- that's what I'm asking." The reply fills in the answer.
• Students expect broadcasts to be "expensive" or special. Clarify: on a switched LAN, broadcasts are common (ARP, DHCP, some discovery protocols) and the switch delivers them to every port by design.

Week 3: IPv4

Pacing: Subnetting is the section that needs the most time. Reserve one full lecture slot for worked examples.

Common blocks:

• Students apply CIDR masks backwards. Reinforce: the "/24" means 24 bits of network, 8 bits of host. AND the address with the mask (255.255.255.0); the result is the network address.
• TTL: students think "time" not "hops." Reinforce: in practice, TTL is decremented once per router hop, not once per second. The name is historical.
• Fragmentation: students find it confusing that DF=1 means "don't fragment." Reinforce the direction: the sender sets DF when it wants to be told if a packet is too large, rather than having it silently split.

Week 4: ICMP

Pacing: Traceroute mechanics are the key insight; spend time on the TTL-incrementing sequence before the lab.

Common blocks:

• Students interpret * * * in traceroute as "the connection failed at that hop." This is wrong; the path continues. Reinforce: * * * means "this router did not respond to ICMP"; it does not mean the path is broken.
• Live traceroute behavior varies by network. Some home routers do not respond; some ISPs block ICMP. Students who see many * * * may think their setup is broken. Verify that the final hop (8.8.8.8 or similar) responds even if middle hops are silent.

Week 5: UDP

Pacing: Two labs in this week (DHCP and DNS). Plan for a full 90-minute lab session. The DHCP lab is faster; the DNS lab with live dig takes more time.

Common blocks:

• Students confuse DHCP "Discover" broadcast scope with "any internet traffic." Reinforce: DHCP broadcasts never leave the local subnet; routers (configured as DHCP relay agents) forward them on large networks.
• The DHCP option field structure is surprising. Students expect fixed-length fields and find the TLV (type-length-value) encoding confusing. Walk through one option manually.
• DNS transaction ID matching: students sometimes do not check the transaction ID and assume any DNS response matches any query. Reinforce: the transaction ID is how a resolver matches replies to its pending queries.

Week 6: TCP I

Pacing: Two labs (handshake + teardown). The handshake trace is the core skill; budget 45-60 minutes for Part 1 of lab-6-1.

Common blocks:

• Sequence number arithmetic is consistently difficult. Walk through at least two examples at the board before the lab: client SYN ISN -> server's ACK = ISN+1; server SYN ISN -> client's ACK = server_ISN+1.
• Students forget that SYN and FIN each consume one sequence number even though they carry no data. This causes off-by-one errors when students trace teardowns.
• RST vs FIN: students think RST is "bad" and FIN is "good." Reinforce that RST is normal in many cases (port not listening, timeout, reboot); it is not inherently malicious.

What to watch: students who cannot trace the three-way handshake SEQ/ACK arithmetic by hand at the end of week 6 will struggle with the TCP parts of the capstone. Extra time in week 6 pays dividends.

Week 7: TCP II

Pacing: Congestion control is conceptual; the lab is observational (reading what Wireshark expert information shows). Do not rush the slow-start explanation; it is counterintuitive.

Common blocks:

• Students conflate flow control (receiver-side window) with congestion control (network-side window). Draw the two-window model: min(rwnd, cwnd). The receiver limits what the network has to carry; the network's capacity limits how fast the sender can push into it.
• "Slow start is exponential, so why is it called slow?" Reinforce: it is slow compared to starting with the full available bandwidth. At 10 MSS initial, it "starts slowly" even though the doubling is fast.

Week 8: DNS

Pacing: dig +trace is the anchor activity. Allow students to run it themselves and read the output before explaining. The tool's output is self-documenting for students who read carefully.

Common blocks:

• Students confuse recursive resolvers and authoritative name servers. The resolver asks on the client's behalf and caches; the authoritative server has the official records. Draw the lookup chain.
• The SOA record's multiple fields are confusing. For week 8, focus on: MNAME (primary NS), RNAME (admin email with dots-as-ats), and the MINIMUM field (negative caching TTL). Skip the refresh/retry/expire fields for now.

Week 9: HTTP

Pacing: Two labs (HTTP trace + pcap-tools tour). The HTTP trace is fast (~30 min). The pcap-tools tour is the longer one; budget the full 45 minutes.

Common blocks:

• Students think the blank line in HTTP (the CRLFCRLF sequence) is optional. It is not. HTTP parsers look for exactly this sequence to delimit headers from body. This is also the reason many HTTP injection bugs work: a crafted header value that embeds CRLFCRLF lets an attacker inject additional headers or responses.
• Students are surprised that curl -v shows TLS output before the HTTP response. Reinforce: TLS wraps HTTP. The TLS handshake completes first; only then can the HTTP request be sent inside the encrypted channel.

Week 10: TLS

Pacing: Two labs (TLS handshake trace + CVE quartet). The handshake lab is a reading exercise; budget 45 minutes. The CVE lab is the more demanding one; students who haven't read the handout before lab will struggle.

Common blocks:

• Students think TLS hides everything. Reinforce what is visible: the SNI in ClientHello, the server certificate (which reveals the hostname and the CA), and the record size/timing patterns. TLS encrypts the content; it does not provide anonymity.
• CVE-2026-5656 is a zip-slip CVE, not a network CVE. Students initially are confused about why it appears in a network-analysis course. Reinforce: the capstone theme is "parsers that process untrusted input." Wireshark processes untrusted .pcap files; that is the same threat model as processing untrusted zip archives.

What to watch: students who cannot explain the ClientHello-ServerHello-Finished sequence by the end of week 10 will struggle in ADV-101 and PEN-101 where TLS is assumed background.

Week 11: NSM and filters

Pacing: Two labs (display filters + Snort/Suricata rules). Lab 11-1 is hands-on filter writing; lab 11-2 is reading comprehension. Plan 45 minutes each.

Common blocks:

• Students write filters that are too broad (e.g., tcp instead of tcp.flags.syn == 1 and tcp.flags.ack == 0). Reinforce: precision matters in NSM. A too-broad filter that shows 90% of packets is not useful.
• Snort/Suricata rule syntax intimidates students who have not seen it before. Remind them: this is a reading exercise. They need to understand each option's purpose, not memorize the syntax. The questions in lab-11-2 scaffold the reading.

Week 12: Capstone

Pacing: The capstone takes the full week. Do not let students start on Day 3. The most common failure mode is insufficient capture content (missing one of the five required protocols).

Common blocks:

• "I cannot see DHCP in my capture." Possible reasons: the device's DHCP lease was already active before capture started; DHCP is suppressed in the lab environment; the student only captured for 2 minutes. Resolution: tell the student to substitute the catalog fixture and note the substitution explicitly.
• "I cannot find an anomaly." Guide the student to look at ARP rate (apply arp and count packets per minute) or DNS queries to unexpected resolver IPs (apply dns and check the destination IPs). Almost every real home network capture has at least one mDNS broadcast, SSDP packet, or unexpected NTP query that counts as "unexpected."
• Undersized reports: the "Key conversations" section is where students do the least work if left to their own devices. Check that they have traced all five protocols and not just described what they saw in general terms.

Grading rubric for the capstone

How to use pcap-tools in lab-mode for graded work

The pcap-tools workbench has two modes:

• Standard mode: student opens any catalog capture and analyzes it independently
• AI Tutor: the AI Tutor overlay is available for non-graded learning; instructors may decide whether to allow it during graded lab sessions

For graded labs, the recommended approach: students work in standard mode without the AI Tutor, then optionally check their answers using the AI Tutor after submitting. The AI Tutor is most valuable for the "why" questions that the workbench itself does not answer.

Forward pointers for instructors

When students ask "what comes next?":

• NET-201 entry: TCP internals (weeks 6-7) and DNS deep-dive (week 8) are the NET-201 foundations. NET-201 week 1 assumes students can trace a TCP session and write display filters.
• PEN-101 entry: weeks 2-3 (Ethernet + IP) and week 6 (TCP) are the PEN-101 on-ramp. Students who cannot trace the three-way handshake will find port-scanning analysis confusing in PEN-101.
• ADV-101 entry: week 10 (TLS + CVE quartet) is the ADV-101 on-ramp. Students who understand the CVE quartet's bug classes at vocabulary level are prepared for ADV-101's deeper CVE analysis.
• SEC-101 entry: weeks 1-10 (the full protocol stack) plus week 11 (NSM) are the SEC-101 foundations. SEC-101 assumes the TCP/IP model is familiar; students who struggled with week 6-7 should review before starting SEC-101.

What NET-101 does NOT teach

• Python socket programming: the public page's 14-week version includes a Python sockets week; v0.1 omits it. Students who want socket programming should look at FND-102 (Python and Automation) or the Beej's Guide readings.
• GNS3 / Cisco Packet Tracer topology simulation: the 14-week public page version references these; v0.1 uses pcap-tools as the primary lab environment and does not require GNS3.
• Suricata/Zeek in production: week 11 introduces rule reading; production deployment is in NET-301.
• IPv6 depth: week 3 gives an overview; IPv6 fundamentals in depth are in NET-201.

Instructor guide v0.1. Revise after first pilot cohort runs.