Sprint: Home/Office Networking Mastery - Real World Projects

Goal: Build a first-principles understanding of how a home or small office network actually moves data, from link layer frames to application responses. You will learn to model, measure, and troubleshoot networks by building real tools that reveal packet flow, addressing, name resolution, routing, and security behavior. You will be able to design and validate a reliable, segmented home/office network, explain the tradeoffs behind every setting, and prove correctness with observable evidence. By the end, you will be able to build and operate the core services and diagnostics that make modern networks work.

Introduction

What is home/office networking? The practical set of protocols, services, and devices that connect endpoints (laptops, phones, printers, servers, IoT) to each other and to the internet.
What problem does it solve today? It delivers reliable, secure connectivity across mixed devices, unpredictable Wi-Fi conditions, and shared uplinks while keeping latency and downtime low.
What will you build across the projects? Scanners, diagnostics, DNS and DHCP services, a router with NAT, packet filters, a proxy, and a basic VPN.
Scope: LAN/Wi-Fi, IP addressing, routing, NAT, TCP/UDP, DNS/DHCP, diagnostics, segmentation, and security.
Out of scope: ISP backbone routing, BGP, large-scale data center networks, and custom switch ASIC design.

Big-picture view:

Home Device            LAN/Wi-Fi            Edge Router              Internet
+------------+     +---------------+     +---------------+       +------------+
| laptop     |<--->| switch/AP     |<--->| NAT + firewall|<----->| DNS/HTTP   |
| phone      |     | ARP, MAC      |     | routing table |       | servers    |
| printer    |     | VLANs         |     | ISP uplink    |       |            |
+------------+     +---------------+     +---------------+       +------------+
     |                    |                     |                       |
     |  L2 frames          |  L3 packets         |  L4 segments          |
     +--------------------+---------------------+-----------------------+

How to Use This Guide

Read the Theory Primer first so the projects feel like applied science instead of guessing.
Pick a learning path that matches your background and time budget.
After each project, validate with the Definition of Done and a packet capture or CLI trace.

Prerequisites & Background Knowledge

Essential Prerequisites (Must Have)

Comfortable with a terminal and basic file editing.
Basic programming skills (loops, conditionals, reading structured data).
Familiarity with IP addresses, ports, and the idea of a request/response.
Recommended Reading: “Computer Networks” by Tanenbaum and Wetherall - Ch. 1
Recommended Reading: “The Linux Command Line” by Shotts - Ch. 1-5

Helpful But Not Required

Basic subnetting (you will learn in Projects 1-4 if not).
Familiarity with Wi-Fi configuration and home routers.
Basic Linux networking tools (ip, ss, tcpdump).

Self-Assessment Questions

Can you explain the difference between a MAC address and an IP address?
Can you read a simple CIDR like 192.168.1.0/24 and describe the usable range?
Can you explain what DNS does before a connection is made?

Development Environment Setup Required Tools:

iproute2 (ip, ss)
tcpdump (packet capture)
dig or nslookup (DNS queries)
traceroute or tracepath
python3 or gcc (to build tools)

Recommended Tools:

Wireshark (GUI packet inspection)
nmap (verification during scanning projects)
iptables or nft (firewall validation)

Testing Your Setup:

$ ip addr show
# You should see at least one interface with an IPv4 address

$ ping -c 1 1.1.1.1
1 packets transmitted, 1 received, 0% packet loss

$ dig example.com +short
93.184.216.34

Time Investment

Simple projects: 4-8 hours each
Moderate projects: 10-20 hours each
Complex projects: 20-40 hours each
Total sprint: 3-6 months (part-time)

Important Reality Check You will be reading packet captures, debugging timeouts, and questioning assumptions. Expect some projects to work only after several rounds of instrumentation and verification. That friction is the point.

Big Picture / Mental Model

Home/office networking is a chain of responsibilities. Each layer is a contract: it promises specific behavior to the layer above and depends on the layer below. When something breaks, you must locate the layer where the contract fails.

Application Goals
    |  (web, video, email)
    v
Transport Contract
    |  (ports, reliability)
    v
Network Contract
    |  (IP routing, addressing)
    v
Link Contract
    |  (MAC delivery on a LAN)
    v
Physical Reality
    |  (RF, cables, interference)
    v
Observable Evidence
    |  (captures, logs, counters)

Theory Primer

Concept 1: Layering and Encapsulation

Fundamentals

Layering is the core mental model of networking. Each layer wraps the data from the layer above with its own header, creating a structure that can be forwarded and understood without needing to interpret higher-level meaning. This is called encapsulation. At the sender, application data becomes a transport segment, then an IP packet, then a link-layer frame, and finally a stream of bits. At the receiver, the process runs in reverse. Layering matters because it limits complexity: you can troubleshoot and replace one layer without rewriting the others. It also shapes failure modes. A broken DNS resolver looks different from a broken Wi-Fi link even though both present as “the internet is down.” Understanding the boundaries and contracts between layers is the prerequisite for every project in this guide.

Deep Dive

Layering is both a conceptual tool and a real architectural boundary. The OSI model is useful vocabulary, while the TCP/IP model represents how systems are actually built. Each layer provides a service to the layer above and consumes a service from the layer below. The practical consequence is that the same application can run over different link types (Ethernet or Wi-Fi) without changing application logic, because the transport and network layers abstract away those differences. Encapsulation is the mechanism that makes this abstraction possible. The application emits bytes; the transport layer adds source and destination ports and reliability metadata; the network layer adds source and destination IP addresses and routing-related fields; the link layer adds source and destination MAC addresses and a frame check sequence. Each hop strips and rewrites only the link-layer envelope while leaving higher layers untouched. This design creates stability but also creates overhead and limits.

The concept of a “layer” is not just a teaching device. It defines the fields you see on the wire and what devices are allowed to change. Switches operate at Layer 2 and rewrite nothing above it. Routers operate at Layer 3 and do not (in principle) modify transport payloads. However, real networks introduce cross-layer devices like NATs, firewalls, and proxies, which inspect or alter information above their nominal layer. This is why you can have a perfectly valid TCP segment that never reaches its destination: the middleboxes change or block it. Learning to see this boundary between ideal layering and real-world layering is essential for debugging home networks.

Layering also explains why maximum transmission unit (MTU) problems are so confusing. The link layer has a maximum frame size (for Ethernet, this is typically 1500 bytes of payload). The IP layer can either fragment larger packets or rely on Path MTU Discovery to avoid fragmentation. Transport protocols like TCP negotiate a maximum segment size (MSS) that fits within the path MTU. If an intermediate device drops ICMP “fragmentation needed” messages, Path MTU Discovery breaks and connections appear to hang only for large transfers. This failure is a cross-layer interaction: a link-layer size limit, an IP-layer fragmentation mechanism, and a transport-layer path discovery algorithm. Layering gives you a vocabulary to explain it, but you must be able to test it with real captures and commands.

Layering is also a performance story. Each layer adds overhead. A tiny application payload can become a much larger frame once transport, network, and link headers are applied. On Wi-Fi, retries and contention can further increase airtime. On a busy home network, that overhead matters. It also affects security: a link-layer encryption protocol like WPA3 protects the frame, but not necessarily the application data once it leaves the Wi-Fi link. Understanding which layer provides confidentiality, integrity, and authentication is a prerequisite for designing secure systems.

Finally, layering shapes how you design tools. A packet sniffer observes data across layers and therefore must decode multiple headers. A port scanner uses the transport layer to infer service behavior. A DNS resolver is an application-layer tool that relies on transport and network layers to function. Each project in this guide is an experiment that isolates and stresses a specific layer contract. The result is a mental model where failures become testable hypotheses rather than mysteries.

How this fit on projects You will repeatedly build tools that operate at specific layers (ARP at link, ping at network, DNS at application). This concept helps you decide which headers to read and which variables to control.

Definitions & key terms

Layer: A conceptual boundary that provides a service to the layer above.
Encapsulation: Wrapping data with headers as it moves down the stack.
Decapsulation: Stripping headers as data moves up the stack.
MTU: Maximum payload size at the link layer.
MSS: Maximum TCP payload size negotiated by endpoints.

Mental model diagram

APP DATA
  |
  v
[ TCP hdr | APP DATA ]
  |
  v
[ IP hdr | TCP hdr | APP DATA ]
  |
  v
[ ETH hdr | IP hdr | TCP hdr | APP DATA | FCS ]
  |
  v
BITS ON THE WIRE

How it works

Application produces bytes.
Transport adds ports and reliability metadata.
Network adds IP addressing and TTL.
Link adds MAC addresses and integrity checks.
Each hop rewrites the link header, not the IP header. Invariants: Higher layers should not depend on link type. Failure modes: MTU mismatch, middlebox interference, incorrect assumptions about which layer provides security.

Minimal concrete example

Encapsulation trace (sizes):
APP payload: 120 bytes
TCP header: 20 bytes
IP header: 20 bytes
Ethernet header + FCS: 18 bytes
Total on wire: 178 bytes

Common misconceptions

“A router forwards frames.” It forwards packets; frames are link-local.
“NAT is security.” NAT is address translation, not a security control.

Check-your-understanding questions

Which layer is responsible for port numbers?
Why does a packet get a new MAC destination at every hop?

Check-your-understanding answers

Transport layer.
MAC addresses are only meaningful within a local link.

Real-world applications

Debugging MTU black holes.
Explaining why Wi-Fi encryption does not secure end-to-end traffic.

Where you will apply it

Projects 1-4, 9, 11, 14, 17

References

“Computer Networks” by Tanenbaum and Wetherall - Ch. 1
“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 1-2

Key insights Encapsulation is the reason you can diagnose failures by layer instead of guessing.

Summary Layering reduces complexity, but real networks leak across layers. You must know both the ideal model and the messy reality.

Homework/Exercises to practice the concept

Draw the encapsulation stack for a DNS query over UDP.
Identify which headers change at each hop in a traceroute.

Solutions to the homework/exercises

APP -> UDP -> IP -> Ethernet, with UDP ports 53.
Link-layer headers change every hop; IP header TTL changes each hop.

Concept 2: Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)

Fundamentals

The link layer is the realm of MAC addresses, frames, and local delivery. It is responsible for getting data from one device to another device on the same local network segment. Ethernet and Wi-Fi are the most common link layers in home and office networks. Ethernet uses switches that learn where MAC addresses live and forward frames to the correct port. Wi-Fi is a shared medium where devices contend for airtime and associate with an access point, which then bridges traffic to the wired LAN. ARP (Address Resolution Protocol) is the bridge between IP and MAC addresses, allowing an IP address to be mapped to a link-layer destination. The link layer defines the boundaries of broadcast domains, which strongly influences performance and security.

Deep Dive

The link layer is the place where “local” really means local. A switch builds a table of MAC address to port mappings by observing the source MAC of incoming frames. When it sees a destination MAC it does not know, it floods the frame out all ports (except the one it arrived on). Over time, this learning behavior makes forwarding efficient, but it also creates risks like MAC table overflow or broadcast storms if the network is poorly segmented. Unlike routers, switches do not understand IP addresses; they only see MACs and EtherType values. This is why ARP is necessary. When a host wants to send to an IP on the same subnet, it broadcasts an ARP request asking who owns that IP, and the owner replies with its MAC. That reply is cached for a limited time. If the cache is stale, ARP traffic increases and devices appear to “mysteriously” fail or slow down.

Wi-Fi adds complexity because the medium is shared and half-duplex. Devices must contend for airtime, and interference or poor signal quality can cause retransmissions that look like packet loss at higher layers. An access point is effectively a bridge between the Wi-Fi link and the wired Ethernet LAN. When you see a device “connected” but unable to reach the internet, the cause could be at the association layer (link) rather than at IP or DNS. Another subtlety is that Wi-Fi uses different frame formats and encryption (WPA2/WPA3) to protect frames on the air. This encryption is per-link, not end-to-end. Once a frame leaves the access point and enters the wired LAN, that Wi-Fi encryption no longer applies.

VLANs are a link-layer technique for segmentation. They allow multiple logical networks to share the same physical switch by tagging frames. In a home/office setting, VLANs are used to separate guest networks or IoT devices from trusted devices. This is a key security and performance tool, but it requires that all participating switches and access points handle VLAN tags correctly. Misconfigured VLAN tagging leads to symptoms like DHCP working on one SSID but not another, or devices that can access the router but not other devices.

Understanding link-layer behavior is essential for building scanners and sniffers. A packet sniffer on a wired switch port sees only the frames destined for that port unless you use port mirroring. On Wi-Fi, you might need monitor mode to see frames not destined for your device. This is a practical limitation that affects how you validate your tools. It is also why many network tools appear to “miss” traffic when run on the wrong interface or in the wrong capture mode.

Finally, link-layer security is not the same as network-layer security. ARP has no authentication, which is why ARP spoofing is possible. Wi-Fi encryption does not prevent a malicious device from joining the network if the passphrase is weak. If you understand the link layer, you can explain and detect these risks with concrete evidence, such as duplicate IP address warnings or sudden changes in ARP cache entries.

How this fit on projects Projects 1, 4, 12, 15, and 18 force you to understand ARP, frames, and capture limitations.

Definitions & key terms

MAC address: A link-layer identifier used for local delivery.
Frame: The unit of data at the link layer.
ARP: Protocol that maps IP addresses to MAC addresses on a LAN.
Broadcast domain: The scope of a link-layer broadcast.
VLAN: A logical segmentation of a link layer.

Mental model diagram

Device A        Switch          Device B
AA:AA           CAM Table       BB:BB
  |                |              |
  | ARP who-has?   | flood        |
  |--------------->|------------->|
  |                | ARP reply    |
  |<---------------|<-------------|
  | data frame     | unicast      |

How it works

Host wants to send to IP in same subnet.
Host broadcasts ARP request for target IP.
Target replies with its MAC address.
Host caches mapping and sends frames directly. Invariants: ARP traffic does not cross routers. Failure modes: ARP cache poisoning, switch flooding, weak Wi-Fi encryption.

Minimal concrete example

ARP exchange (text):
Request: Who has 192.168.1.50? Tell 192.168.1.10
Reply: 192.168.1.50 is at 00:11:22:33:44:55

Common misconceptions

“Switches block broadcasts.” Switches forward broadcasts to all ports.
“Wi-Fi is just wireless Ethernet.” The medium behavior and security differ.

Check-your-understanding questions

Why does ARP not work across subnets?
What does a switch do with an unknown destination MAC?

Check-your-understanding answers

ARP requests are link-local broadcasts; routers do not forward them.
It floods the frame out all ports except the ingress port.

Real-world applications

Diagnosing why a device is visible but not reachable.
Segmenting IoT devices with VLANs and guest Wi-Fi.

Where you will apply it

Projects 1, 4, 12, 15, 18

References

“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 2, 4
RFC 826 (ARP)

Key insights The link layer is the truth of local delivery; everything else is built on it.

Summary Mastering ARP, MACs, and switching gives you real control over your LAN behavior.

Homework/Exercises to practice the concept

Map your own ARP cache and identify every device.
Draw your network and mark the broadcast domain boundaries.

Solutions to the homework/exercises

Use arp -a and compare with your router client list.
Each router boundary separates a broadcast domain.

Concept 3: IP Addressing, Subnetting, and Routing (Including NAT)

Fundamentals

IP is the addressing and routing system of the internet. IPv4 uses 32-bit addresses and relies on subnet masks (CIDR) to determine which destinations are local versus remote. Your device sends local traffic directly and remote traffic to the default gateway (your router). Routing is a hop-by-hop decision made by routers using the longest prefix match in the routing table. NAT (Network Address Translation) is common at the edge: it maps many private addresses to a single public address. Subnetting is the tool that partitions a network into smaller segments, which is critical for performance, security, and scaling in home/office environments.

Deep Dive

An IP address has two parts: the network prefix and the host identifier. CIDR notation (for example, /24) tells you how many bits belong to the prefix. The prefix defines the boundary of local delivery. If the destination IP shares the same prefix, the host uses ARP to find the destination MAC and sends directly. If not, it sends to the default gateway. This simple rule explains most “why can’t I reach this device” problems. Subnetting is the practice of choosing a prefix length that fits your network size and segmentation goals. Too large a subnet creates unnecessary broadcast traffic and larger failure domains. Too small a subnet causes address shortages or awkward routing rules.

Routing decisions are made by examining the destination IP and finding the most specific (longest) match in the routing table. A default route (0.0.0.0/0) catches everything else. Each router decrements the TTL field, which prevents routing loops from persisting forever. When TTL reaches zero, the router drops the packet and sends an ICMP Time Exceeded message. This is the mechanism that traceroute exploits. In home networks, your router usually has a handful of routes: the local LAN, perhaps a guest LAN, and a default route to your ISP. But in small office networks, you might add static routes to reach a lab subnet, or a VPN route to reach a remote office. Misconfigured routes cause asymmetric paths, which are hard to debug without captures.

NAT adds a stateful translation table at the edge. It replaces private source IPs and ports with a public IP and a chosen source port (often called PAT). When replies come back, the router uses this table to translate them back to the internal host. This is how many devices share one public address. NAT also breaks the original end-to-end model of the internet, which is why inbound connections typically require explicit port forwarding. Understanding NAT is critical for troubleshooting “I can browse the web but cannot host a server” issues, and for understanding why some peer-to-peer applications struggle. NAT is not a firewall, but it has similar observable effects because unsolicited inbound traffic is dropped by default when no translation table entry exists.

IPv6 changes the addressing landscape. It uses 128-bit addresses, removing the need for NAT at the edge. Instead of ARP, IPv6 uses Neighbor Discovery (ND). IPv6 hosts often use Stateless Address Autoconfiguration (SLAAC) to build their own addresses from router advertisements. In practice, many home networks operate dual-stack (IPv4 and IPv6). This means troubleshooting can involve two parallel protocol stacks, with different failure modes. A device might fail over IPv4 but work over IPv6, or the reverse. Understanding IP addressing at both versions makes you far more effective at diagnosing real-world issues.

Finally, routing and addressing are where policy is enforced. VLANs map to IP subnets. Firewall rules frequently reference IP ranges. VPNs create new routes. If you know how to design and reason about addresses and routing tables, you can predict how traffic will flow before you even run a packet capture. That ability is what transforms you from a user of networks into an engineer of networks.

How this fit on projects Subnet math and routing logic are required for Projects 1-3, 9, 14, 18, and 19.

Definitions & key terms

CIDR: Prefix notation for networks (e.g., /24).
Default gateway: Router used for off-subnet traffic.
Longest prefix match: Routing rule that chooses the most specific route.
NAT/PAT: Translation of internal addresses to a public address with ports.

Mental model diagram

LAN 192.168.1.0/24       Router/NAT          Internet
Host 192.168.1.50  ->  [NAT table]  ->  203.0.113.5:45001

How it works

Host checks if destination is in local subnet.
If local, ARP and send directly; if not, send to gateway.
Router chooses route via longest prefix match.
NAT rewrites source IP/port for outbound flows. Invariants: TTL always decrements at routers. Failure modes: wrong subnet mask, missing default route, NAT table exhaustion.

Minimal concrete example

Routing table snippet:
192.168.1.0/24 -> eth0 (direct)
0.0.0.0/0 -> 192.168.1.1 (default)

Common misconceptions

“Two devices with the same IP will work if they are on different switches.” They will conflict if on the same subnet.
“NAT protects me from all inbound attacks.” It does not replace a firewall.

Check-your-understanding questions

Why does a /24 network have 254 usable addresses?
What happens when no route matches a destination?

Check-your-understanding answers

Two addresses are reserved: network and broadcast.
The packet is dropped (and often an ICMP unreachable is sent).

Real-world applications

Planning guest and IoT subnets.
Diagnosing port forwarding and inbound access problems.

Where you will apply it

Projects 1-3, 9, 14, 18, 19

References

“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 3
RFC 791 (IPv4), RFC 8200 (IPv6)

Key insights Addressing and routing are the map; NAT and policy are the gatekeepers.

Summary If you can compute subnets and read routing tables, you can predict traffic flow.

Homework/Exercises to practice the concept

Divide 192.168.10.0/24 into four /26 subnets.
Sketch a routing table for a network with a guest VLAN and a VPN.

Solutions to the homework/exercises

/26 blocks at .0, .64, .128, .192.
Include routes for each subnet plus a default route to the ISP.

Concept 4: Transport and Ports (TCP and UDP)

Fundamentals

The transport layer provides end-to-end communication between applications. TCP offers reliable, ordered delivery through acknowledgments, retransmission, and flow control. UDP provides minimal overhead without reliability guarantees, which makes it ideal for low-latency or simple query/response protocols like DNS. Ports are the addressing mechanism for applications. A network connection is identified by a 5-tuple: source IP, source port, destination IP, destination port, and protocol. Understanding how TCP and UDP differ is essential for building tools like ping-like diagnostics, port scanners, and proxies.

Deep Dive

TCP is a stateful protocol. It begins with a three-way handshake that establishes initial sequence numbers on both ends. Once established, each side maintains a sliding window of bytes that have been sent but not yet acknowledged. Retransmission occurs on timeout or after duplicate acknowledgments. Flow control uses the receiver’s advertised window to prevent buffer overflow, while congestion control reacts to signs of network congestion by reducing the sending rate. These behaviors are not just theoretical: they explain why a large file transfer can slow down after packet loss, and why a connection may stall if ACKs are filtered or delayed.

UDP is the opposite: it simply wraps application data with source and destination ports and a checksum. There is no handshake, no retransmission, and no ordering. This makes UDP great for short queries, live streaming, or gaming, where timeliness is more important than perfect delivery. But it also means that the application must handle loss, duplication, or reordering if those problems matter. This is why protocols like DNS and DHCP include their own retry logic and transaction IDs.

Ports are the multiplexing mechanism of the transport layer. A single IP address can host many services because each service listens on a different port. Clients use ephemeral ports chosen by the OS to distinguish their connections. Firewalls and NAT devices often make decisions based on ports and protocol state, which is why understanding TCP states (SYN_SENT, ESTABLISHED, FIN_WAIT) is crucial for debugging. For example, a firewall that drops inbound SYN packets but allows inbound ACKs can cause mysterious failures in connection setup while established connections continue to work.

Transport behavior is also shaped by MTU and fragmentation. TCP segments are sized to fit within the path MTU. If a segment is too large and fragmentation is blocked, the connection can stall in ways that appear random. UDP has no built-in recovery for lost fragments, which can make large UDP payloads unreliable. This is why many UDP-based protocols keep messages small or implement their own segmentation and reassembly.

When you build transport-layer tools, you are interacting with a state machine. A port scanner that uses TCP SYN packets is testing how a host responds to a state transition. A proxy server is managing two concurrent TCP state machines and relaying data between them. A VPN tunnel often runs over UDP or TCP and must handle reliability differently depending on the transport. The more you understand transport mechanics, the more precise your debugging and design choices become.

How this fit on projects Projects 2, 3, 9, 11, 17, and 19 depend directly on transport behavior.

Definitions & key terms

5-tuple: The identifiers of a transport flow.
Handshake: TCP connection establishment.
Window: Flow control mechanism for TCP.
Ephemeral port: Temporary client port assigned by the OS.

Mental model diagram

Client                     Server
SYN  -------------------->  (listening)
SYN-ACK <------------------
ACK  -------------------->  (established)

How it works

TCP establishes state via handshake.
Data is sent with sequence numbers and ACKs.
Loss triggers retransmission and window reduction.
UDP sends without state; application handles retries if needed. Invariants: TCP guarantees order if the connection stays up. Failure modes: half-open connections, blocked SYNs, dropped ACKs.

Minimal concrete example

UDP request/response:
Client -> UDP:53 query id=0x1234
Server -> UDP:53 response id=0x1234

Common misconceptions

“UDP is always faster.” It can be, but loss may negate benefits.
“TCP guarantees delivery across the internet.” It only guarantees delivery within the connection’s lifetime.

Check-your-understanding questions

Why does a TCP connection need both sequence and acknowledgment numbers?
When would you choose UDP over TCP for a home network tool?

Check-your-understanding answers

To track sent bytes and confirm receipt in order.
For low-latency, small messages where retries are acceptable.

Real-world applications

Reliable file transfer versus real-time streaming.
Port scanning and service discovery.

Where you will apply it

Projects 2, 3, 9, 11, 17, 19

References

RFC 9293 (TCP), RFC 768 (UDP)
“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 11-16

Key insights Transport protocols are state machines; your tools must respect their state.

Summary TCP and UDP make different promises. Your designs must align with those promises.

Homework/Exercises to practice the concept

List three application protocols that use UDP and why.
Draw the TCP close sequence and label each side’s state.

Solutions to the homework/exercises

DNS (small queries), NTP (time sync), VoIP (latency).
FIN/ACK exchange with TIME_WAIT on the side that closes last.

Concept 5: Naming and Configuration Services (DNS, DHCP, mDNS)

Fundamentals

Before a connection happens, a device needs two things: an address configuration and a name-to-address mapping. DHCP provides configuration: IP address, subnet mask, default gateway, and DNS servers. DNS provides name resolution: it turns a human-friendly name into IP addresses. On small local networks without an authoritative DNS server, mDNS and DNS-SD allow devices to discover services on the local link. These services are essential because users do not type IP addresses and devices do not manually configure themselves in modern networks.

Deep Dive

DNS is a hierarchical distributed database. When a client needs to resolve a name, it asks a recursive resolver (often provided by the ISP or a local router). The resolver performs iterative queries starting at the root, then the TLD, then the authoritative server for the zone. Responses are cached according to TTL values. This caching is why DNS queries can be fast, and also why changes can take time to propagate. DNS responses can arrive over UDP for small messages or TCP for larger responses or zone transfers. Understanding this distinction matters for debugging, since UDP truncation forces a TCP retry.

DHCP follows a discover-offer-request-acknowledge (DORA) exchange. A client with no address broadcasts a DHCPDISCOVER. A server replies with a DHCPOFFER. The client requests the offered address with DHCPREQUEST, and the server confirms with DHCPACK. Leases are time-limited and periodically renewed. This system allows dynamic reuse of addresses and centralized configuration. But it also introduces failure modes: multiple DHCP servers can fight, leases can expire if the server is unreachable, and clients can receive inconsistent options (like a wrong default gateway) that make the network appear partially broken.

mDNS and DNS-SD provide zero-configuration discovery. Instead of contacting a DNS server, devices send multicast queries to a well-known address on the local link. This allows discovery of printers, media devices, and local services without manual setup. The protocol reuses DNS message formats but changes the transport and scope. mDNS is powerful for home networks but can become noisy in larger environments. Understanding the scope and TTL settings for mDNS is essential when diagnosing why a device appears in a discovery list but is not reachable, or why service lists change frequently.

Naming and configuration services also intersect with security. DNS can be spoofed if you trust the wrong resolver or if a local attacker injects responses. DHCP can be abused by rogue servers. This is why managed networks often implement DHCP snooping and DNS security mechanisms. In home networks, the threat model is different, but the failure modes are similar. A misbehaving IoT device running a DHCP server can cause intermittent failures that look like random internet drops.

Finally, these services are the backbone of usability. When DNS or DHCP fails, users perceive that “the internet is down,” even if the physical link is fine. Your ability to build a DNS resolver or DHCP server from scratch is a demonstration that you truly understand how network configuration and naming work. It also makes you capable of implementing local overrides like DNS sinkholes, which are highly practical for security and ad-blocking.

How this fit on projects Projects 5-8, 10, and 16 are direct applications of DNS, DHCP, and mDNS.

Definitions & key terms

Resolver: The client-side DNS component that asks questions.
Recursive resolver: DNS server that walks the hierarchy on behalf of clients.
TTL: Time-to-live for cached DNS answers.
Lease: The time a DHCP address is valid.
mDNS: Multicast DNS on a local link.

Mental model diagram

Client -> Resolver -> Root -> TLD -> Authoritative
          ^ cache TTLs at each step

How it works

Client obtains an IP address and DNS server via DHCP.
Client asks resolver for a name.
Resolver walks the DNS hierarchy and caches answers.
Local devices use mDNS for link-local discovery. Invariants: DNS is cached and hierarchical. Failure modes: rogue DHCP, stale DNS cache, mDNS storms.

Minimal concrete example

DNS query/response (text):
Query: A example.com
Answer: example.com -> 93.184.216.34 (TTL 86400)

Common misconceptions

“DNS is always real-time.” It is cached by design.
“DHCP only gives IP addresses.” It also provides gateway and DNS servers.

Check-your-understanding questions

Why might a DNS change take hours to show up?
What happens if a DHCP lease expires and the server is down?

Check-your-understanding answers

Cached answers remain valid until TTL expires.
The client may lose connectivity or fall back to a self-assigned address.

Real-world applications

Local ad-blocking via DNS sinkholes.
Zero-configuration printer discovery.

Where you will apply it

Projects 5-8, 10, 16

References

RFC 1034/1035 (DNS), RFC 2131 (DHCP)
RFC 6762/6763 (mDNS, DNS-SD)

Key insights Naming and configuration are invisible until they fail, then everything fails.

Summary DNS and DHCP are the core control plane of a home network.

Homework/Exercises to practice the concept

Trace a DNS lookup from your device to the authoritative server.
Capture a DHCP DORA exchange and label each step.

Solutions to the homework/exercises

Use dig +trace and note each delegation.
Filter UDP ports 67 and 68 and identify discover, offer, request, ack.

Concept 6: Operations, Diagnostics, and Security

Fundamentals

Diagnostics and security are where theory becomes practical. ICMP provides feedback about connectivity, latency, and routing failures. Tools like ping and traceroute rely on ICMP to make network paths visible. Packet capture reveals the truth of what is happening on the wire, which is essential when logs or assumptions are wrong. Security in home/office networks is built on segmentation, stateful filtering, and secure Wi-Fi configuration. Understanding these tools and controls lets you diagnose failures quickly and prevent common threats.

Deep Dive

ICMP is often misunderstood as “just ping,” but it is the control plane of IP. It reports unreachable destinations, TTL expiry, and fragmentation requirements. Traceroute manipulates TTL values to force routers along a path to send ICMP Time Exceeded messages, which reveals hop-by-hop routing. Understanding ICMP types and codes lets you differentiate between “host unreachable” and “port unreachable,” which can save hours of guessing. But ICMP is not guaranteed to be delivered, so diagnostics must be combined with other evidence like TCP resets and packet captures.

Packet capture is the definitive tool for understanding network behavior. A capture shows headers at every layer, timestamps, retransmissions, and the exact sequence of events that produced a failure. It also reveals hidden behaviors, such as DNS retries, TCP window size changes, or unexpected multicast traffic. Effective capture requires careful filtering and knowledge of what you are looking for. On switched networks, you may only see traffic destined for your host, so you may need port mirroring or monitor mode on Wi-Fi. Without this awareness, you can falsely conclude that traffic is not present when you are simply not observing the right link.

Security in home networks is primarily about reducing attack surface and limiting trust. A stateful firewall tracks connection state and allows return traffic while blocking unsolicited inbound flows. This is different from NAT, though NAT produces a similar effect. Segmentation isolates devices so that a compromised IoT device cannot reach sensitive systems. Wi-Fi security must protect the air interface using WPA2 or WPA3, and should avoid legacy configurations like WEP or open networks. VPNs create encrypted tunnels across untrusted networks; they can be site-to-site (linking networks) or remote access (linking a device to a network). VPNs also alter routing by creating new routes over the tunnel interface, which is why they sometimes break local network access or change DNS behavior.

Operational visibility is not just about troubleshooting failures. It is about validating performance and policy. A bandwidth monitor can show whether a device is saturating the uplink. A DNS sinkhole can show which devices are contacting malicious domains. A firewall log can show attempted scans or misconfigured services. These tools are the foundation of a healthy home or office network.

Finally, security is a system property, not a single setting. A strong Wi-Fi passphrase is meaningless if devices are on the same flat network with no segmentation. A firewall rule is only as good as the routing table that feeds it. The projects in this guide are structured to force you to test and verify these properties, not just configure them.

How this fit on projects Projects 2-4, 9-20 use diagnostics and security concepts directly.

Definitions & key terms

ICMP: Control messages for IP.
Stateful firewall: Filters traffic based on connection state.
Segmentation: Separating devices into isolated networks.
VPN: Encrypted tunnel over untrusted networks.

Mental model diagram

Client -> Router -> Internet
   |        |         |
   |   firewall state |
   |   ICMP feedback  |
   +-> capture point  |

How it works

Use ICMP to test reachability and path.
Capture packets to confirm actual behavior.
Enforce policy with firewall and segmentation.
Use VPNs to extend trust securely. Invariants: ICMP is best-effort, not guaranteed. Failure modes: blocked ICMP, asymmetric routing, misapplied firewall rules.

Minimal concrete example

Traceroute logic:
TTL=1 -> ICMP Time Exceeded from hop 1
TTL=2 -> ICMP Time Exceeded from hop 2
...

Common misconceptions

“If ping fails, the host is down.” ICMP may be blocked.
“NAT equals firewall.” NAT does not express security policy.

Check-your-understanding questions

Why can traceroute fail even when the destination is reachable?
Why might a VPN break access to local printers?

Check-your-understanding answers

Routers or hosts may block ICMP Time Exceeded messages.
VPN routes may override local routes, sending traffic into the tunnel.

Real-world applications

Diagnosing intermittent Wi-Fi dropouts.
Segmenting IoT devices away from trusted systems.

Where you will apply it

Projects 2-4, 9-20

References

RFC 792 (ICMP)
“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 6

Key insights You cannot secure or fix what you cannot observe.

Summary Diagnostics and security are practical disciplines that transform network theory into reliable systems.

Homework/Exercises to practice the concept

Capture a TCP handshake and annotate each packet.
Design a guest network segmentation plan for your home.

Solutions to the homework/exercises

Identify SYN, SYN-ACK, ACK, then the first data packet.
Create a separate VLAN or SSID with no access to LAN subnets.

Glossary

ARP: Protocol that resolves IP addresses to MAC addresses on a LAN.
Broadcast domain: A link-layer segment that receives broadcasts.
CIDR: Prefix notation describing subnet boundaries.
Default gateway: Router used for off-subnet traffic.
DNS: Distributed naming system mapping names to records.
DHCP: Protocol for automatic IP configuration.
ICMP: Control protocol used for diagnostics and errors.
MTU: Maximum transmission unit at the link layer.
NAT: Address translation at a network edge.
Port: Transport-layer identifier for an application endpoint.
TCP: Reliable transport protocol.
UDP: Best-effort transport protocol.
VLAN: Logical segmentation at the link layer.
VPN: Encrypted tunnel over an untrusted network.
mDNS: Multicast DNS for local service discovery.

Why Home/Office Networking Matters

Modern work and learning depend on stable, secure home networks (remote work, cloud apps, video conferencing).
Home networks are now multi-device environments with mixed trust levels (laptops, phones, IoT, guests).
DNS, DHCP, and NAT failures are among the most common real-world causes of “the internet is down.”
Real-world statistics and impact:
- 5.5 billion people are online in 2024, about 68% of the global population (ITU Facts and Figures 2024).
- In the United States, 80% of adults subscribe to home broadband and 95% use the internet (Pew Research Center survey, 2023; published 2024).

Context and evolution (brief):

Ethernet and Wi-Fi became the default home link layers.
NAT became the standard edge pattern due to IPv4 scarcity.
WPA3 (2018) modernized Wi-Fi security to reduce offline password guessing.

Old vs new home network model:

Old (flat LAN)                     New (segmented LAN)
+-----------+                      +-----------+
| All devices|                      | Trusted   |
| same subnet|                      | subnet    |
| same access|                      +-----------+
+-----------+                            |
       |                                 |
       v                                 v
   Single router                     Guest/IoT subnet

Concept Summary Table

Concept Cluster	What You Need to Internalize
Layering and Encapsulation	How headers wrap data and how layer boundaries define failure modes.
Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)	MAC addressing, ARP behavior, switching, and Wi-Fi link realities.
IP Addressing, Subnetting, and Routing (Including NAT)	Subnets, default gateways, longest prefix match, and NAT behavior.
Transport and Ports (TCP and UDP)	TCP/UDP state, ports, and how services map to flows.
Naming and Configuration Services (DNS, DHCP, mDNS)	DNS resolution, caching, DHCP leases, and mDNS discovery.
Operations, Diagnostics, and Security	ICMP, captures, firewall state, segmentation, and VPN tunnels.

Project-to-Concept Map

Project	Concepts Applied
Project 1	Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching); IP Addressing, Subnetting, and Routing (Including NAT)
Project 2	Transport and Ports (TCP and UDP); Operations, Diagnostics, and Security
Project 3	IP Addressing, Subnetting, and Routing (Including NAT); Operations, Diagnostics, and Security
Project 4	Layering and Encapsulation; Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)
Project 5	Naming and Configuration Services (DNS, DHCP, mDNS); Transport and Ports (TCP and UDP)
Project 6	Naming and Configuration Services (DNS, DHCP, mDNS); IP Addressing, Subnetting, and Routing (Including NAT)
Project 7	Naming and Configuration Services (DNS, DHCP, mDNS); Transport and Ports (TCP and UDP)
Project 8	Naming and Configuration Services (DNS, DHCP, mDNS); IP Addressing, Subnetting, and Routing (Including NAT)
Project 9	Transport and Ports (TCP and UDP); Operations, Diagnostics, and Security
Project 10	Naming and Configuration Services (DNS, DHCP, mDNS); Operations, Diagnostics, and Security
Project 11	Transport and Ports (TCP and UDP); Layering and Encapsulation
Project 12	Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching); Operations, Diagnostics, and Security
Project 13	Operations, Diagnostics, and Security; IP Addressing, Subnetting, and Routing (Including NAT)
Project 14	IP Addressing, Subnetting, and Routing (Including NAT); Transport and Ports (TCP and UDP)
Project 15	Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching); Operations, Diagnostics, and Security
Project 16	Naming and Configuration Services (DNS, DHCP, mDNS); Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)
Project 17	Transport and Ports (TCP and UDP); Operations, Diagnostics, and Security
Project 18	Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching); IP Addressing, Subnetting, and Routing (Including NAT)
Project 19	Transport and Ports (TCP and UDP); Operations, Diagnostics, and Security
Project 20	Layering and Encapsulation; Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching); IP Addressing, Subnetting, and Routing (Including NAT); Transport and Ports (TCP and UDP); Naming and Configuration Services (DNS, DHCP, mDNS); Operations, Diagnostics, and Security

Deep Dive Reading by Concept

Concept	Book and Chapter	Why This Matters
Layering and Encapsulation	“Computer Networks” by Tanenbaum and Wetherall - Ch. 1	Builds the base model and vocabulary.
Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching)	“TCP/IP Illustrated, Vol 1” by Stevens - Ch. 2, 4	Ethernet framing and ARP in depth.
IP Addressing, Subnetting, and Routing (Including NAT)	“TCP/IP Illustrated, Vol 1” - Ch. 3	IPv4 headers, fragmentation, and routing.
Transport and Ports (TCP and UDP)	“TCP/IP Illustrated, Vol 1” - Ch. 11-16	TCP/UDP behavior and state transitions.
Naming and Configuration Services (DNS, DHCP, mDNS)	“TCP/IP Illustrated, Vol 1” - Ch. 18-19, 21	DNS and BOOTP/DHCP mechanics.
Operations, Diagnostics, and Security	“Understanding Linux Network Internals” by Benvenuti - Ch. 1-3	Practical diagnostic and filtering insight.

Quick Start: Your First 48 Hours

Day 1:

Read the Theory Primer chapters on Layering, Link Layer, and IP Addressing.
Start Project 1 and get a basic ARP discovery running.

Day 2:

Validate Project 1 against the Definition of Done.
Read the Core Question and Pitfalls sections for Project 2 and 3.

Recommended Learning Paths

Path 1: The Home Tinkerer

Project 1 -> Project 2 -> Project 5 -> Project 10 -> Project 12

Path 2: The Systems Builder

Project 1 -> Project 4 -> Project 9 -> Project 14 -> Project 17

Path 3: The Security-Minded Operator

Project 5 -> Project 10 -> Project 13 -> Project 19 -> Project 20

Success Metrics

You can explain any network failure in terms of a specific layer contract.
You can capture traffic and prove why a connection succeeds or fails.
You can design a segmented home network and justify the routing and firewall rules.

Appendix: Packet Anatomy and MTU Cheat Sheet

Common header sizes (bytes)

Ethernet header + FCS: 18
IPv4 header (no options): 20
TCP header (no options): 20
UDP header: 8

MTU rules of thumb

Ethernet MTU (payload): 1500
Typical TCP MSS: 1460 (1500 - 20 - 20)
Typical UDP payload for DNS: 512 (legacy limit; larger with EDNS0)

Appendix: Capture and Troubleshooting Workflow

Basic capture workflow

Identify the interface: ip link.
Capture only what you need: tcpdump -n -i <iface> port 53.
Correlate timestamps with logs.

Layered troubleshooting checklist

Link: Is the device associated? Can you see ARP?
Network: Do routes and subnets match? Is the gateway reachable?
Transport: Are SYNs answered? Are UDP replies seen?
Application: Are DNS answers valid? Is HTTP responding?

Project Overview Table

Project	Difficulty	Time	Core Outcome
1. Network Device Scanner	Level 1	Weekend	Discover LAN devices via ARP
2. Build Your Own ping	Level 2	Week	ICMP echo and RTT stats
3. Build Your Own traceroute	Level 2	Week	Path discovery via TTL
4. Packet Sniffer	Level 2	Week	Capture and decode frames
5. DNS Resolver	Level 2	Week	Recursive DNS resolution
6. DHCP Client	Level 2	Week	Acquire leases via DORA
7. Simple DNS Server	Level 3	2 weeks	Authoritative zone service
8. DHCP Server	Level 3	2 weeks	Lease management and options
9. Port Scanner	Level 2	Week	Service discovery by port
10. DNS Sinkhole	Level 3	2 weeks	Block domains at DNS layer
11. Simple HTTP Server	Level 2	Week	Serve basic HTTP responses
12. Bandwidth Monitor	Level 2	Week	Per-device traffic stats
13. Packet Filter Firewall	Level 3	2 weeks	Stateful filtering rules
14. Software Router with NAT	Level 4	3-4 weeks	Route and translate traffic
15. Wake-on-LAN Tool	Level 1	Weekend	Send magic packets
16. mDNS Service Discovery	Level 2	Week	Discover local services
17. HTTP Proxy Server	Level 3	2 weeks	Intercept and log traffic
18. Network Topology Mapper	Level 3	2-3 weeks	Map devices and links
19. Simple VPN Server	Level 4	4 weeks	Encrypted tunnel
20. Home Network Capstone	Level 4	4-6 weeks	Full integrated stack

Project List

The following projects guide you from basic LAN discovery to building a full home network stack with routing, services, and security.

Project 1: Network Device Scanner (ARP Discovery Tool)

File: P01-network-device-scanner.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 1: Beginner
Knowledge Area: LAN Discovery / ARP
Software or Tool: Similar to arp-scan or nmap -sn
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A CLI tool that discovers all devices on your local network by sending ARP requests and collecting replies.

Why it teaches networking: ARP is the bridge between IP addresses and physical devices. If you can implement ARP discovery, you understand how LAN communication actually works.

Core challenges you will face:

Crafting link-layer requests -> maps to Link Layer and LAN
Subnet range calculation -> maps to IP Addressing and Routing
Response correlation and timing -> maps to Operations and Diagnostics

Real World Outcome

You run the scanner and get a device table with IP, MAC, and vendor lookup:

$ sudo ./lan_scan
Scanning 192.168.1.0/24 on en0...

IP Address       MAC Address          Vendor
-----------------------------------------------------
192.168.1.1      aa:bb:cc:11:22:33    Netgear
192.168.1.12     10:aa:bb:cc:dd:ee    Apple
192.168.1.25     b8:27:eb:12:34:56    Raspberry Pi
192.168.1.80     44:55:66:77:88:99    Samsung

Found 4 devices in 2.1 seconds

The Core Question You Are Answering

“How does my computer discover who is on the local network without any central directory?”

This project makes ARP visible and forces you to handle real broadcast behavior and timing.

Concepts You Must Understand First

MAC addressing and OUIs
- What do the first 3 bytes represent?
- Book Reference: “Computer Networks” - Ch. 4
ARP request/reply flow
- Why does ARP use broadcast for requests and unicast for replies?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 4
Subnet math
- How do you compute host ranges from CIDR?
- Book Reference: “TCP/IP Guide” - Ch. 10

Questions to Guide Your Design

Packet construction
- What fields must be set for a valid ARP request?
- How do you specify broadcast at the link layer?
Scanning strategy
- Sequential vs parallel probing: how do you trade speed and noise?
- How long do you wait before declaring a host silent?

Thinking Exercise

Trace a single ARP discovery

Draw the exact frames exchanged when your laptop discovers the router’s MAC for the first time.

Questions to answer:

Which fields change between request and reply?
Where is the mapping cached after the exchange?

The Interview Questions They Will Ask

“Why does ARP not cross router boundaries?”
“What is a broadcast domain, and how does it affect ARP?”
“How would you detect ARP spoofing on a LAN?”
“What happens when two devices claim the same IP?”
“Why is ARP still used in IPv4 but not in IPv6?”

Hints in Layers

Hint 1: Start small Probe a single known IP first and confirm you can see the reply with tcpdump.

Hint 2: Choose the right interface Scanning on the wrong interface yields no replies. Verify with ip addr or ifconfig.

Hint 3: Pseudocode outline

- read local IP and subnet mask
- compute host range
- for each host: send ARP who-has
- wait for replies for N seconds
- parse replies into table

Hint 4: Verification tools Use arp -a and tcpdump -n -e arp to validate traffic.

Books That Will Help

Topic	Book	Chapter
ARP protocol	“TCP/IP Illustrated, Vol 1”	Ch. 4
Ethernet framing	“Computer Networks”	Ch. 4
Subnet math	“TCP/IP Guide”	Ch. 10

Common Pitfalls and Debugging

Problem 1: “No replies at all”

Why: Wrong interface or Wi-Fi client isolation.
Fix: Select the active interface; test on wired LAN if possible.
Quick test: tcpdump -n -e arp

Problem 2: “Only some devices show up”

Why: Devices asleep or behind another subnet.
Fix: Wake devices or limit scanning to local subnet.
Quick test: Ping a target then rescan.

Definition of Done

Scanner lists at least 3 known LAN devices
Results include IP and MAC for each device
Output is reproducible across two runs
A packet capture confirms ARP requests and replies

Project 2: Build Your Own ping Utility

File: P02-build-your-own-ping.md
Main Programming Language: C
Alternative Programming Languages: Python, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 2: Intermediate
Knowledge Area: ICMP / Diagnostics
Software or Tool: ping
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A ping clone that sends ICMP echo requests, measures RTT, and summarizes loss.

Why it teaches networking: ICMP reveals the health of the network layer and teaches raw packet handling.

Core challenges you will face:

ICMP message construction -> maps to Operations and Diagnostics
Checksum calculation -> maps to Layering and Encapsulation
Accurate timing -> maps to Transport and Ports

Real World Outcome

$ sudo ./myping example.com
PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=54 time=18.1 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=17.8 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=54 time=18.9 ms
^C
--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss
round-trip min/avg/max = 17.8/18.3/18.9 ms

The Core Question You Are Answering

“How does the network layer prove reachability without TCP or UDP?”

Concepts You Must Understand First

ICMP types and codes
- What is Echo Request vs Echo Reply?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 6
Checksum basics
- Why does ICMP need a checksum?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 3
Raw sockets and privileges
- Why are elevated permissions needed?
- Book Reference: “UNIX Network Programming, Vol 1” - Ch. 28

Questions to Guide Your Design

Packet format
- What fields must be set in an ICMP echo request?
- How do you match replies to requests?
Timing and statistics
- When do you start and stop the timer?
- How do you compute min/avg/max without storing everything?

Thinking Exercise

TTL thought experiment

If you send ICMP with TTL=1 to a remote host, what response should you expect and why?

Questions to answer:

Which device generates the response?
What ICMP type is returned?

The Interview Questions They Will Ask

“Why does ping use ICMP instead of TCP?”
“What does TTL tell you in a ping response?”
“Why might ping fail even when a host is reachable?”
“How is the ICMP checksum computed?”
“What is the security risk of allowing ping?”

Hints in Layers

Hint 1: Verify on the wire Capture with tcpdump -n icmp to confirm you are sending valid packets.

Hint 2: Keep the payload small Start with a fixed payload size to simplify checksum handling.

Hint 3: Pseudocode outline

- build ICMP echo request
- compute checksum
- send packet
- wait for reply with timeout
- compute RTT and print

Hint 4: Compare with system ping Run system ping to compare TTL and RTT ranges.

Books That Will Help

Topic	Book	Chapter
ICMP	“TCP/IP Illustrated, Vol 1”	Ch. 6
Raw sockets	“UNIX Network Programming, Vol 1”	Ch. 28
Checksums	“TCP/IP Illustrated, Vol 1”	Ch. 3

Common Pitfalls and Debugging

Problem 1: “Replies never arrive”

Why: ICMP blocked by firewall or raw socket permissions.
Fix: Test with system ping and confirm privileges.
Quick test: sudo ping -c 1 1.1.1.1

Problem 2: “RTT values are negative or zero”

Why: Timer started after send or incorrect time source.
Fix: Start timer before sending and use monotonic clock.
Quick test: Compare with system ping output.

Definition of Done

Sends ICMP echo requests with valid checksum
Receives and validates replies
Computes RTT and packet loss
Output matches system ping within reasonable tolerance

Project 3: Build Your Own traceroute Utility

File: P03-build-your-own-traceroute.md
Main Programming Language: C
Alternative Programming Languages: Python, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 2: Intermediate
Knowledge Area: Routing / ICMP
Software or Tool: traceroute
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A traceroute clone that maps the hop-by-hop path to a destination.

Why it teaches networking: It reveals how routers forward packets and how TTL controls path visibility.

Core challenges you will face:

TTL manipulation -> maps to IP Addressing and Routing
ICMP time exceeded parsing -> maps to Operations and Diagnostics
Timing and retries -> maps to Transport and Ports

Real World Outcome

$ sudo ./mytrace example.com
192.168.1.1   1.2 ms  1.0 ms  1.1 ms
10.0.0.1      8.4 ms  7.9 ms  8.1 ms
203.0.113.9   15.3 ms 15.0 ms 15.2 ms
198.51.100.5  25.0 ms 24.7 ms 25.4 ms
93.184.216.34 34.1 ms 33.9 ms 34.2 ms

The Core Question You Are Answering

“What path does my traffic take, and which router boundaries exist between me and a destination?”

Concepts You Must Understand First

TTL behavior
- How does TTL prevent loops?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 8
ICMP Time Exceeded
- What generates it and what data it includes?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 6
Routing basics
- Why do hops change at router boundaries?
- Book Reference: “Computer Networks” - Ch. 5

Questions to Guide Your Design

Probe type
- Use UDP probes or ICMP echo? What tradeoffs?
Timeout and retries
- How many probes per hop? How long to wait?

Thinking Exercise

TTL ladder

Predict what you should see for TTL values 1, 2, and 3 when tracing to a remote host.

Questions to answer:

Which hop will send the ICMP reply?
What changes between hops besides RTT?

The Interview Questions They Will Ask

“How does traceroute work at the protocol level?”
“Why can traceroute results differ between runs?”
“What is the difference between UDP-based and ICMP-based traceroute?”
“Why might some hops show as * * *?”
“What does a sudden RTT spike at a hop indicate?”

Hints in Layers

Hint 1: Start with a small max hop Limit max hops to avoid long runs while debugging.

Hint 2: Capture ICMP replies Filter for ICMP type 11 to validate the TTL behavior.

Hint 3: Pseudocode outline

for ttl in 1..max:
  send probe with TTL
  wait for ICMP time exceeded or destination reached
  record hop IP and RTT

Hint 4: Compare with system traceroute Run traceroute or tracepath and compare hop counts.

Books That Will Help

Topic	Book	Chapter
ICMP errors	“TCP/IP Illustrated, Vol 1”	Ch. 6
Routing	“Computer Networks”	Ch. 5
IP header	“TCP/IP Illustrated, Vol 1”	Ch. 3

Common Pitfalls and Debugging

Problem 1: “All hops are * * *“

Why: ICMP replies blocked by routers or firewall.
Fix: Try ICMP-based probes or different destination.
Quick test: Run system traceroute for comparison.

Problem 2: “Stops early”

Why: Destination blocked, rate-limited, or TTL max too low.
Fix: Increase max hops and adjust timeouts.
Quick test: Use ping to confirm reachability.

Definition of Done

Shows hop-by-hop IPs up to destination
RTTs are measurable and reasonable
Handles timeouts gracefully
Output comparable to system traceroute

Project 4: Network Packet Sniffer

File: P04-network-packet-sniffer.md
Main Programming Language: C
Alternative Programming Languages: Python, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: Packet Capture / Encapsulation
Software or Tool: tcpdump / Wireshark
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A sniffer that captures frames, decodes Ethernet and IP headers, and prints a readable summary.

Why it teaches networking: You will see the full stack on the wire and verify encapsulation in practice.

Core challenges you will face:

Capture permissions and interfaces -> maps to Operations and Diagnostics
Header parsing -> maps to Layering and Encapsulation
Filtering and output formatting -> maps to Link Layer and LAN

Real World Outcome

$ sudo ./sniff --iface en0 --filter "tcp"
[14:32:01.102] ETH src=aa:bb:cc:11:22:33 dst=ff:ff:ff:ff:ff:ff type=0x0800
            IP  src=192.168.1.12 dst=93.184.216.34 ttl=64 proto=TCP
            TCP sport=52344 dport=443 flags=SYN

The Core Question You Are Answering

“What is actually on the wire when my computer talks to the internet?”

Concepts You Must Understand First

Ethernet framing
- What fields make up an Ethernet II frame?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 2
IPv4 header layout
- Which fields matter for routing and validation?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 3
Capture scope
- Why do you only see some traffic on a switched network?
- Book Reference: “Understanding Linux Network Internals” - Ch. 1

Questions to Guide Your Design

Parsing order
- How do you detect EtherType and decide next header?
Performance
- How will you avoid dropping packets under load?

Thinking Exercise

Parse by hand

Given a hex dump of an Ethernet frame, identify where the IP header starts.

Questions to answer:

How many bytes are in the Ethernet header?
How do you tell whether it is IPv4 or ARP?

The Interview Questions They Will Ask

“Why does a sniffer miss traffic on a switched network?”
“What is promiscuous mode and why is it required?”
“How do you identify TCP vs UDP in a capture?”
“What is the difference between capture filters and display filters?”
“Why might capture timestamps be inaccurate?”

Hints in Layers

Hint 1: Start with Ethernet only Decode only Ethernet headers before adding IP parsing.

Hint 2: Use small filters Capture just ARP or ICMP while testing to reduce noise.

Hint 3: Pseudocode outline

- open capture on interface
- read raw frame bytes
- parse Ethernet header
- if IPv4: parse IP header
- if TCP/UDP: print ports

Hint 4: Validation Compare your output against tcpdump -n -e for the same traffic.

Books That Will Help

Topic	Book	Chapter
Ethernet	“TCP/IP Illustrated, Vol 1”	Ch. 2
IPv4	“TCP/IP Illustrated, Vol 1”	Ch. 3
Linux capture	“Understanding Linux Network Internals”	Ch. 1

Common Pitfalls and Debugging

Problem 1: “Capture shows nothing”

Why: Wrong interface or missing permissions.
Fix: Use the correct interface and run with elevated privileges.
Quick test: tcpdump -n -i <iface> -c 1

Problem 2: “Parsed fields look wrong”

Why: Misaligned offsets or wrong byte order.
Fix: Validate header sizes and use network byte order.
Quick test: Compare with Wireshark field values.

Definition of Done

Captures frames on a chosen interface
Correctly prints Ethernet and IP fields
Differentiates TCP vs UDP
Output matches tcpdump for test traffic

Project 5: DNS Resolver (Client-Side)

File: P05-dns-resolver-client.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: DNS / Application Layer
Software or Tool: dig / nslookup
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A DNS resolver that performs iterative queries and returns A and AAAA records.

Why it teaches networking: It exposes how naming really works and why DNS caching matters.

Core challenges you will face:

Parsing DNS messages -> maps to Naming and Configuration Services
Iterative resolution -> maps to Transport and Ports
Caching behavior -> maps to Operations and Diagnostics

Real World Outcome

$ ./resolve example.com
Query: A example.com
Answer: 93.184.216.34
Trace:
  root -> .com -> example.com
Cache: stored for 86400 seconds

The Core Question You Are Answering

“How does a name become an IP address without a single global database?”

Concepts You Must Understand First

DNS message format
- How are questions and answers encoded?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 18
Recursive vs iterative resolution
- What does a resolver actually do step-by-step?
- Book Reference: “Computer Networks” - Ch. 7
UDP transport
- Why does DNS typically use UDP?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 11

Questions to Guide Your Design

Resolver strategy
- How will you choose root servers?
- When do you retry over TCP?
Caching
- Where and how will you store TTL-based cache entries?

Thinking Exercise

Name resolution trace

Write the sequence of DNS queries from root to authoritative for example.com.

Questions to answer:

What records are returned at each step?
Which responses are cached?

The Interview Questions They Will Ask

“What is the difference between recursive and iterative DNS?”
“Why does DNS use UDP by default?”
“What happens when a DNS response is truncated?”
“How does TTL affect caching and consistency?”
“How would you detect DNS poisoning on a LAN?”

Hints in Layers

Hint 1: Start with a single record type Support A records first, then add AAAA.

Hint 2: Use known root hints Start with a root server list and iterate.

Hint 3: Pseudocode outline

- build DNS query
- send to root server
- follow referrals until authoritative
- return final answer
- cache by TTL

Hint 4: Verification Compare your output to dig +trace example.com.

Books That Will Help

Topic	Book	Chapter
DNS basics	“TCP/IP Illustrated, Vol 1”	Ch. 18-19
DNS at scale	“Computer Networks”	Ch. 7
UDP transport	“TCP/IP Illustrated, Vol 1”	Ch. 11

Common Pitfalls and Debugging

Problem 1: “Stuck in referral loop”

Why: Not following NS records correctly.
Fix: Parse authority and additional sections carefully.
Quick test: Compare with dig +trace output.

Problem 2: “Some domains fail”

Why: No TCP fallback on truncation.
Fix: Detect truncation flag and retry over TCP.
Quick test: Query a DNSSEC-signed domain with large responses.

Definition of Done

Resolves A and AAAA records via iterative queries
Displays the referral chain
Implements TTL-based caching
Matches results from dig +trace

Project 6: DHCP Client

File: P06-dhcp-client.md
Main Programming Language: C
Alternative Programming Languages: Python, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 2: Intermediate
Knowledge Area: DHCP / IP Configuration
Software or Tool: DHCP client
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A DHCP client that obtains an IP lease and prints configuration details.

Why it teaches networking: It exposes how devices self-configure and why networks break when DHCP fails.

Core challenges you will face:

Broadcast messaging -> maps to Link Layer and LAN
Lease handling -> maps to Naming and Configuration Services
Parsing options -> maps to Layering and Encapsulation

Real World Outcome

$ sudo ./dhcp_client
Sending DHCPDISCOVER...
Received DHCPOFFER from 192.168.1.1
Requesting 192.168.1.120...
Lease ACK received
IP: 192.168.1.120
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 1.1.1.1, 8.8.8.8
Lease: 86400 seconds

The Core Question You Are Answering

“How does a device with no address join a network automatically?”

Concepts You Must Understand First

DORA exchange
- What happens in discover, offer, request, ack?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 21
UDP broadcast mechanics
- Why are ports 67/68 used?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 11
DHCP options
- Which options are required for basic connectivity?
- Book Reference: RFC 2131

Questions to Guide Your Design

State handling
- How do you track transaction IDs and retries?
Lease timing
- When should renew and rebind happen?

Thinking Exercise

Lease expiry scenario

If a client cannot contact the DHCP server at renewal time, what should it do?

Questions to answer:

What is the difference between renew and rebind?
When does the client drop the lease?

The Interview Questions They Will Ask

“Why does DHCP use broadcast instead of unicast?”
“What information does DHCP provide beyond IP address?”
“What happens if two DHCP servers respond?”
“How does a client renew its lease?”
“How can you troubleshoot DHCP failures?”

Hints in Layers

Hint 1: Start with printing packets Log each DORA message to prove the state machine.

Hint 2: Use transaction IDs Match replies by transaction ID to avoid confusion.

Hint 3: Pseudocode outline

- broadcast DHCPDISCOVER
- wait for DHCPOFFER
- send DHCPREQUEST
- receive DHCPACK
- parse options and print

Hint 4: Verification Capture UDP ports 67/68 to confirm correct fields.

Books That Will Help

Topic	Book	Chapter
DHCP	“TCP/IP Illustrated, Vol 1”	Ch. 21
UDP	“TCP/IP Illustrated, Vol 1”	Ch. 11
Configuration	“Computer Networks”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “No offer received”

Why: Wrong interface or blocked broadcast.
Fix: Bind to correct interface and verify broadcast is allowed.
Quick test: Capture DHCPOFFER with tcpdump.

Problem 2: “Lease obtained but no internet”

Why: Missing gateway or DNS option.
Fix: Validate DHCP options and print them clearly.
Quick test: Compare with system DHCP client output.

Definition of Done

Completes DORA exchange
Parses and prints IP, mask, gateway, DNS
Handles retries and timeouts
Packet capture matches DHCP spec

Project 7: Simple DNS Server (Authoritative)

File: P07-simple-dns-server.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: DNS Server / Application Layer
Software or Tool: Similar to BIND or Unbound (authoritative mode)
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A minimal authoritative DNS server that serves a local zone file.

Why it teaches networking: Serving DNS forces you to understand message formats, record types, and authoritative responses.

Core challenges you will face:

Zone file parsing -> maps to Naming and Configuration Services
UDP and TCP DNS handling -> maps to Transport and Ports
Correct flags and responses -> maps to Layering and Encapsulation

Real World Outcome

$ dig @127.0.0.1 home.lan A

;; ANSWER SECTION:
home.lan.   300   IN   A   192.168.1.10

The Core Question You Are Answering

“How does an authoritative DNS server answer for a zone with full control?”

Concepts You Must Understand First

DNS header fields
- Which flags indicate authoritative answers?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 18
Record types
- What is the difference between A, AAAA, CNAME, and MX?
- Book Reference: RFC 1035
UDP vs TCP in DNS
- When does DNS switch to TCP?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 11

Questions to Guide Your Design

Zone format
- How will you store and load records?
Response construction
- How will you build responses with correct TTL and flags?

Thinking Exercise

Zone design

Design a zone file for home.lan with a router, a NAS, and a printer.

Questions to answer:

Which records are necessary?
What TTLs make sense for a home network?

The Interview Questions They Will Ask

“What makes a DNS server authoritative?”
“Why are TTL values important?”
“When does DNS use TCP?”
“How do you handle unknown record types?”
“What is the role of NS records in a zone?”

Hints in Layers

Hint 1: Start with a tiny zone Serve only A records for a small test domain.

Hint 2: Verify with dig Use dig @127.0.0.1 and confirm flags.

Hint 3: Pseudocode outline

- parse zone file into records
- receive DNS query
- match name and type
- build response with AA flag

Hint 4: TCP fallback Handle TCP queries when the client retries for large responses.

Books That Will Help

Topic	Book	Chapter
DNS message format	“TCP/IP Illustrated, Vol 1”	Ch. 18
DNS server design	“Computer Networks”	Ch. 7
DNS standards	RFC 1034/1035	Spec

Common Pitfalls and Debugging

Problem 1: “Client says SERVFAIL”

Why: Incorrect flags or malformed response.
Fix: Compare your response to dig +trace output.
Quick test: Validate packet with Wireshark DNS dissector.

Problem 2: “Records not found”

Why: Case or trailing dot issues in names.
Fix: Normalize names and enforce FQDN format.
Quick test: Query with and without trailing dots.

Definition of Done

Serves at least 5 records for a local zone
Responses set authoritative flag
Works with dig and nslookup
Handles UDP and TCP queries

Project 8: DHCP Server

File: P08-dhcp-server.md
Main Programming Language: C
Alternative Programming Languages: Python, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: DHCP / Network Services
Software or Tool: Similar to dnsmasq (DHCP mode)
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A DHCP server that hands out leases, tracks allocations, and provides options.

Why it teaches networking: It reveals the control plane of local addressing and client configuration.

Core challenges you will face:

Lease management -> maps to Naming and Configuration Services
Broadcast handling -> maps to Link Layer and LAN
Options and policy -> maps to Operations and Diagnostics

Real World Outcome

$ sudo ./dhcp_server
Listening on 0.0.0.0:67
Lease offered: 192.168.1.150 to 70:3a:cb:aa:bb:cc
Lease ACK: 192.168.1.150 (86400s)

The Core Question You Are Answering

“How does a network centrally control who gets an address and what configuration they receive?”

Concepts You Must Understand First

DHCP state machine
- How does the server decide which offer to make?
- Book Reference: RFC 2131
Lease database design
- How do you store state across restarts?
- Book Reference: “Computer Networks” - Ch. 7
Broadcast and relay
- How does DHCP work across subnets?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 21

Questions to Guide Your Design

Address pool policy
- How do you avoid collisions? How do you reserve static leases?
Option handling
- Which options are required for functional internet access?

Thinking Exercise

Competing DHCP servers

Describe what happens if two DHCP servers respond to the same client.

Questions to answer:

How does the client choose an offer?
How can you prevent conflicts?

The Interview Questions They Will Ask

“Why does DHCP require a server-side lease database?”
“What is a DHCP relay and when is it used?”
“What options are essential for internet access?”
“How can you detect rogue DHCP servers?”
“What happens when the lease pool is exhausted?”

Hints in Layers

Hint 1: Implement basic DORA first Ignore advanced options until the base exchange works.

Hint 2: Log every state change A visible lease table will save you time.

Hint 3: Pseudocode outline

- listen for DHCPDISCOVER
- select available IP from pool
- send DHCPOFFER
- on DHCPREQUEST, confirm and ACK
- store lease with expiration

Hint 4: Verification Use a VM or test device to request a lease and compare with system DHCP server.

Books That Will Help

Topic	Book	Chapter
DHCP protocol	“TCP/IP Illustrated, Vol 1”	Ch. 21
DHCP details	RFC 2131	Spec
Network services	“Computer Networks”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “Client never completes DORA”

Why: Missing required options or wrong transaction ID handling.
Fix: Match transaction IDs and include subnet mask and router options.
Quick test: Capture DHCP traffic with tcpdump -n port 67 or 68.

Problem 2: “Leases are duplicated”

Why: Lease database not persisted or not locked.
Fix: Persist lease state and lock during allocation.
Quick test: Restart server and request multiple leases.

Definition of Done

Issues leases from a defined pool
Provides gateway and DNS options
Stores and reuses leases
Handles lease expiration

Project 9: Port Scanner

File: P09-port-scanner.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: Transport / Service Discovery
Software or Tool: Similar to nmap
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A port scanner that identifies open TCP and UDP ports on a host.

Why it teaches networking: It forces you to reason about TCP states, timeouts, and service responses.

Core challenges you will face:

TCP handshake behavior -> maps to Transport and Ports
Timeout strategies -> maps to Operations and Diagnostics
Ethical scanning limits -> maps to Security

Real World Outcome

$ ./scan 192.168.1.10
Open TCP ports:
  22 (ssh)
  80 (http)
  443 (https)

Open UDP ports:
  53 (dns)

The Core Question You Are Answering

“How can I infer what services are running on a host without logging in?”

Concepts You Must Understand First

TCP handshake states
- What does SYN-ACK vs RST mean?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 13
UDP behavior
- How do you detect UDP openness without a handshake?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 11
Rate limiting and ethics
- Why can scanning be disruptive?
- Book Reference: “Computer Networks” - Ch. 8 (security)

Questions to Guide Your Design

Scanning strategy
- How many ports per second is safe on a LAN?
Result classification
- How do you distinguish closed, filtered, and open?

Thinking Exercise

TCP response logic

If you send a SYN to a closed port, what response should you expect?

Questions to answer:

How is this different from a filtered port?
How would you detect rate limiting?

The Interview Questions They Will Ask

“Why does TCP SYN scanning work?”
“How can you scan UDP ports reliably?”
“What is the difference between closed and filtered ports?”
“How can a firewall hide ports?”
“What are ethical scanning practices on a LAN?”

Hints in Layers

Hint 1: Start with a small port list Scan just 22, 80, 443 to validate logic.

Hint 2: Add parallelism carefully Avoid flooding your LAN and triggering rate limits.

Hint 3: Pseudocode outline

- for each port:
    - send TCP SYN
    - if SYN-ACK: open
    - if RST: closed
    - if timeout: filtered

Hint 4: Verification Use ss -tln on the target host (if you control it) to confirm results.

Books That Will Help

Topic	Book	Chapter
TCP states	“TCP/IP Illustrated, Vol 1”	Ch. 13-15
UDP scanning	“TCP/IP Illustrated, Vol 1”	Ch. 11
Security basics	“Computer Networks”	Ch. 8

Common Pitfalls and Debugging

Problem 1: “Everything looks closed”

Why: Scanning blocked by firewall or wrong target.
Fix: Verify target is reachable with ping and check firewall.
Quick test: Scan a known open port on localhost.

Problem 2: “UDP results are inconsistent”

Why: UDP has no handshake, responses may be absent.
Fix: Use service-specific probes or ICMP unreachable checks.
Quick test: Scan a known UDP service like DNS.

Definition of Done

Detects open and closed TCP ports correctly
Provides a reasonable heuristic for UDP ports
Respects rate limits and timeouts
Results verified against a known host

Project 10: DNS Sinkhole (Pi-hole Style)

File: P10-dns-sinkhole.md
Main Programming Language: Python
Alternative Programming Languages: Go, Rust, C
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: DNS Security / Network Control
Software or Tool: Similar to Pi-hole
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A DNS forwarder that blocks requests for known ad or malware domains.

Why it teaches networking: It combines DNS understanding with security policy and observability.

Core challenges you will face:

DNS response manipulation -> maps to Naming and Configuration Services
Logging and analytics -> maps to Operations and Diagnostics
Blocklist management -> maps to Security

Real World Outcome

$ ./dns_sinkhole --listen 0.0.0.0:53
Blocked: ads.example.net -> 0.0.0.0
Allowed: example.com -> 93.184.216.34
Top blocked domains today:
  ads.example.net (245)
  tracker.example.org (188)

The Core Question You Are Answering

“How can DNS be used as a control point to protect and shape network behavior?”

Concepts You Must Understand First

DNS forwarding
- How do you relay queries to upstream resolvers?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 18
NXDOMAIN vs sinkhole
- Which response should you return and why?
- Book Reference: RFC 1035
Logging and privacy
- What should be logged, and what should not?
- Book Reference: “Computer Networks” - Ch. 8

Questions to Guide Your Design

Policy enforcement
- How do you match domains and subdomains efficiently?
Performance
- How do you avoid slowing down normal DNS resolution?

Thinking Exercise

Blocklist tradeoff

If you block ads.example.com, what happens to cdn.ads.example.com?

Questions to answer:

How should wildcard matching work?
What are the false positive risks?

The Interview Questions They Will Ask

“What is a DNS sinkhole and how does it work?”
“How do you prevent blocking critical domains?”
“Why might returning NXDOMAIN break apps?”
“How can you measure the effectiveness of a sinkhole?”
“What privacy considerations exist when logging DNS queries?”

Hints in Layers

Hint 1: Start as a pure forwarder Forward all queries to an upstream resolver first.

Hint 2: Add a simple blocklist Block a fixed list of domains to validate logic.

Hint 3: Pseudocode outline

- receive DNS query
- if domain in blocklist: return sinkhole answer
- else: forward to upstream, return response
- log decision

Hint 4: Verification Use dig to confirm blocked vs allowed responses.

Books That Will Help

Topic	Book	Chapter
DNS forwarding	“TCP/IP Illustrated, Vol 1”	Ch. 18
DNS protocol	RFC 1035	Spec
Security context	“Computer Networks”	Ch. 8

Common Pitfalls and Debugging

Problem 1: “Everything is blocked”

Why: Overly broad domain matching.
Fix: Use exact match and explicit wildcards.
Quick test: Query a known safe domain and verify.

Problem 2: “Responses are slow”

Why: No caching or slow upstream resolver.
Fix: Add a small cache and measure upstream latency.
Quick test: Compare with dig response times.

Definition of Done

Forwards allowed domains correctly
Blocks listed domains with a clear response
Logs decisions with timestamps
Caching improves response time

Project 11: Simple HTTP Server

File: P11-simple-http-server.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: Application Protocols / TCP
Software or Tool: Minimal HTTP server
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A basic HTTP server that serves static responses and logs requests.

Why it teaches networking: It connects transport-layer mechanics to real application protocols.

Core challenges you will face:

TCP connection handling -> maps to Transport and Ports
Request parsing -> maps to Layering and Encapsulation
Concurrency and timeouts -> maps to Operations and Diagnostics

Real World Outcome

$ curl -i http://localhost:8080/
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 18

Hello from LAN

The Core Question You Are Answering

“What does a real application protocol look like over raw TCP?”

Concepts You Must Understand First

TCP streams
- Why is TCP a byte stream, not message-based?
- Book Reference: “UNIX Network Programming, Vol 1” - Ch. 1-3
HTTP basics
- What defines a request line and headers?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 14
Connection lifecycle
- How do you handle multiple clients safely?
- Book Reference: “Computer Networks” - Ch. 6

Questions to Guide Your Design

Parsing and buffering
- How do you detect end of headers?
Concurrency
- Will you handle one request at a time or many?

Thinking Exercise

Partial reads

How do you handle a request that arrives in multiple TCP segments?

Questions to answer:

What indicates the end of the headers?
What if the client sends more data after the headers?

The Interview Questions They Will Ask

“Why is HTTP built on TCP rather than UDP?”
“How do you know when an HTTP request is complete?”
“What is keep-alive and why does it matter?”
“How do you prevent a slow client from blocking others?”
“What is the difference between HTTP and HTTPS?”

Hints in Layers

Hint 1: Start with a fixed response Serve a static string for every request.

Hint 2: Print raw requests Log incoming bytes to understand headers.

Hint 3: Pseudocode outline

- accept TCP connection
- read until blank line
- parse request line
- write response headers and body

Hint 4: Verification Use curl -i and compare with expected output.

Books That Will Help

Topic	Book	Chapter
TCP streams	“UNIX Network Programming, Vol 1”	Ch. 1-3
HTTP over TCP	“TCP/IP Illustrated, Vol 1”	Ch. 14
Concurrency	“Computer Networks”	Ch. 6

Common Pitfalls and Debugging

Problem 1: “Client hangs”

Why: Server does not send Content-Length or close connection.
Fix: Provide Content-Length or close after response.
Quick test: Compare headers with curl -i.

Problem 2: “Requests are partial”

Why: TCP segmentation splits the headers.
Fix: Read until header terminator sequence.
Quick test: Simulate slow client with nc.

Definition of Done

Serves a valid HTTP response
Handles multiple requests sequentially without crashing
Logs request method and path
Works with curl and a browser

Project 12: Bandwidth Monitor

File: P12-bandwidth-monitor.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Traffic Monitoring / Observability
Software or Tool: Similar to iftop or nethogs
Main Book: “Understanding Linux Network Internals” by Christian Benvenuti

What you will build: A real-time bandwidth monitor that aggregates traffic by device and protocol.

Why it teaches networking: It forces you to understand traffic measurement, packet capture limits, and aggregation.

Core challenges you will face:

Packet capture and filtering -> maps to Operations and Diagnostics
Mapping IPs to devices -> maps to Link Layer and LAN
Rate calculations -> maps to Transport and Ports

Real World Outcome

$ sudo ./bandwidth_watch --iface en0
Device                In (kbps)   Out (kbps)   Top Protocol
192.168.1.12           820         120         HTTPS
192.168.1.25            40         560         DNS
192.168.1.80            15          22         NTP

The Core Question You Are Answering

“Who is consuming bandwidth on my network, and how do I prove it?”

Concepts You Must Understand First

Packet capture scope
- What traffic can you see from a single interface?
- Book Reference: “Understanding Linux Network Internals” - Ch. 1
Flow identification
- How do you group packets by device or protocol?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 12
Sampling vs full capture
- When is sampling accurate enough?
- Book Reference: “Computer Networks” - Ch. 6

Questions to Guide Your Design

Aggregation logic
- Do you aggregate by IP, MAC, or both?
Time windows
- How do you compute rates over sliding windows?

Thinking Exercise

Observation bias

If your capture point is on your laptop, what traffic will you miss?

Questions to answer:

How does switching affect visibility?
What would change with a mirror port?

The Interview Questions They Will Ask

“Why might a bandwidth monitor under-report usage?”
“How would you map traffic to devices reliably?”
“What are the limits of monitoring on Wi-Fi?”
“How do you compute throughput from packet captures?”
“How would you detect a single device saturating the uplink?”

Hints in Layers

Hint 1: Start with total bytes Compute total bytes per second before adding per-device logic.

Hint 2: Use short windows A 1-2 second window provides responsive updates.

Hint 3: Pseudocode outline

- capture packets
- extract src/dst IP and length
- update counters per device
- print rates every second

Hint 4: Verification Compare totals with ifconfig or ip -s link counters.

Books That Will Help

Topic	Book	Chapter
Packet capture	“Understanding Linux Network Internals”	Ch. 1
TCP/UDP flow IDs	“TCP/IP Illustrated, Vol 1”	Ch. 12
Traffic measurement	“Computer Networks”	Ch. 6

Common Pitfalls and Debugging

Problem 1: “Rates fluctuate wildly”

Why: Too short or inconsistent time windows.
Fix: Use a fixed interval and a rolling average.
Quick test: Compare to a known download speed.

Problem 2: “Missing devices”

Why: Capture point only sees local traffic.
Fix: Capture on router or mirror port if possible.
Quick test: Generate traffic from a known device and confirm visibility.

Definition of Done

Reports per-device throughput
Updates at regular intervals
Uses a consistent capture filter
Results match interface counters within tolerance

Project 13: Simple Packet Filter Firewall

File: P13-simple-packet-filter-firewall.md
Main Programming Language: C
Alternative Programming Languages: Go, Rust, Python
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Firewall / Security
Software or Tool: Similar to iptables/nftables (minimal)
Main Book: “Understanding Linux Network Internals” by Christian Benvenuti

What you will build: A minimal packet filter that allows or blocks traffic based on IP, port, and state.

Why it teaches networking: It forces you to think about policy, connection state, and safe defaults.

Core challenges you will face:

State tracking -> maps to Transport and Ports
Rule evaluation -> maps to Operations and Security
Logging and visibility -> maps to Operations and Diagnostics

Real World Outcome

$ sudo ./mini_fw --allow tcp:22 --allow tcp:443 --deny all
Rule set loaded: 2 allow, 1 deny
Blocked: 192.168.1.50 -> 93.184.216.34:80 (tcp)
Allowed: 192.168.1.50 -> 93.184.216.34:443 (tcp)

The Core Question You Are Answering

“How do firewalls actually decide which packets to allow or block?”

Concepts You Must Understand First

Stateful vs stateless filtering
- Why is state important for TCP?
- Book Reference: “Computer Networks” - Ch. 8
5-tuple flows
- How do you identify a connection?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 13
Default deny
- Why is “deny by default” a best practice?
- Book Reference: “Understanding Linux Network Internals” - Ch. 3

Questions to Guide Your Design

Rule structure
- How will rules be ordered and matched?
State table
- How will you expire inactive flows?

Thinking Exercise

Half-open connections

What should the firewall do with a SYN-ACK that has no known SYN?

Questions to answer:

Is it part of an existing flow?
Should it be logged or blocked?

The Interview Questions They Will Ask

“What is the difference between stateless and stateful firewalls?”
“Why should inbound traffic be blocked by default?”
“How do you handle UDP with no connection state?”
“What does a firewall log tell you during an incident?”
“How can firewall rules break DNS or DHCP?”

Hints in Layers

Hint 1: Start with stateless rules Allow or deny based on IP and port before adding state.

Hint 2: Log everything initially Logging makes rule behavior visible during testing.

Hint 3: Pseudocode outline

- parse rules into ordered list
- for each packet: find matching rule
- if TCP and rule allows: update state table
- log decision

Hint 4: Verification Use curl and dig to test allowed vs blocked flows.

Books That Will Help

Topic	Book	Chapter
Netfilter concepts	“Understanding Linux Network Internals”	Ch. 3
Transport state	“TCP/IP Illustrated, Vol 1”	Ch. 13
Security model	“Computer Networks”	Ch. 8

Common Pitfalls and Debugging

Problem 1: “Everything blocked”

Why: Rule order or missing allow rules for DNS/DHCP.
Fix: Add explicit DNS and DHCP rules before deny all.
Quick test: Run dig and DHCP renew.

Problem 2: “Connections drop after a while”

Why: State table expiration too aggressive.
Fix: Tune idle timeouts for TCP and UDP.
Quick test: Keep a connection open and observe.

Definition of Done

Applies ordered allow/deny rules
Tracks TCP state for established flows
Logs decisions with reasons
Allows essential services and blocks others by default

Project 14: Software Router with NAT

File: P14-software-router-with-nat.md
Main Programming Language: C
Alternative Programming Languages: Go, Rust
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Routing / NAT
Software or Tool: Minimal software router
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A user-space router that forwards packets between interfaces and performs NAT.

Why it teaches networking: It forces you to implement routing, translation, and policy from scratch.

Core challenges you will face:

Route lookup -> maps to IP Addressing and Routing
NAT table management -> maps to IP Addressing and Routing
Performance and correctness -> maps to Operations and Diagnostics

Real World Outcome

$ sudo ./soft_router --lan en0 --wan en1
Routing table loaded: 2 routes
NAT enabled: public 203.0.113.5
Translation: 192.168.1.12:51510 -> 203.0.113.5:40002

The Core Question You Are Answering

“How does a home router actually forward and translate traffic?”

Concepts You Must Understand First

Routing table logic
- How does longest prefix match work?
- Book Reference: “Computer Networks” - Ch. 5
NAT/PAT behavior
- How do you map many internal hosts to one external IP?
- Book Reference: RFC 3022
Checksum updates
- Which headers must be updated after NAT?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 3

Questions to Guide Your Design

Forwarding pipeline
- In what order do you apply route lookup and NAT?
State tracking
- How do you expire idle translations safely?

Thinking Exercise

Inbound flow

How does a reply packet know which internal host to reach after NAT?

Questions to answer:

What key does the NAT table use?
What happens if the entry has expired?

The Interview Questions They Will Ask

“Why does NAT break the end-to-end model?”
“How do routers decide which interface to forward on?”
“Why must checksums be updated after translation?”
“What does port forwarding do?”
“How can NAT table exhaustion affect a network?”

Hints in Layers

Hint 1: Start with pure forwarding Get routing without NAT working first.

Hint 2: Implement a small NAT table Use a fixed-size table with clear expiration rules.

Hint 3: Pseudocode outline

- receive packet on interface
- look up route by destination IP
- if outbound: rewrite src IP/port and update checksum
- if inbound: reverse-lookup NAT table and rewrite dst
- forward to next hop

Hint 4: Verification Use a test host behind the router and confirm internet access.

Books That Will Help

Topic	Book	Chapter
Routing	“Computer Networks”	Ch. 5
IP header	“TCP/IP Illustrated, Vol 1”	Ch. 3
NAT	RFC 3022	Spec

Common Pitfalls and Debugging

Problem 1: “Forwarding works, NAT fails”

Why: Checksums not updated or NAT table lookup wrong.
Fix: Recompute checksums and log table entries.
Quick test: Capture packets and compare pre/post translation.

Problem 2: “Inbound traffic never reaches host”

Why: No NAT state or port forward.
Fix: Ensure translation exists or configure port forwarding rules.
Quick test: Inspect NAT table on inbound packet.

Definition of Done

Forwards packets between interfaces correctly
Performs outbound NAT and reverse inbound translation
Maintains NAT state with timeouts
Validated via end-to-end connectivity test

Project 15: Wake-on-LAN Tool

File: P15-wake-on-lan.md
Main Programming Language: Python
Alternative Programming Languages: C, Go, Rust
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 1. The “Resume Gold”
Difficulty: Level 1: Beginner
Knowledge Area: Link Layer / Broadcast
Software or Tool: Wake-on-LAN
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A tool that sends a magic packet to wake a sleeping device.

Why it teaches networking: It reveals how link-layer broadcasts can trigger device behavior.

Core challenges you will face:

Magic packet format -> maps to Link Layer and LAN
Broadcast delivery -> maps to Operations and Diagnostics
Device compatibility -> maps to Real-world troubleshooting

Real World Outcome

$ ./wol 00:11:22:33:44:55
Sent magic packet to 192.168.1.255
Device 00:11:22:33:44:55 is now reachable

The Core Question You Are Answering

“How can a device be woken by a packet when it is powered down?”

Concepts You Must Understand First

Broadcast on LAN
- Why does a broadcast reach sleeping devices?
- Book Reference: “Computer Networks” - Ch. 4
Magic packet format
- What is the byte pattern required?
- Book Reference: Vendor documentation (NIC)
LAN boundaries
- Why does Wake-on-LAN usually not cross routers?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 2

Questions to Guide Your Design

Delivery method
- Do you use UDP broadcast or raw Ethernet frames?
Validation
- How do you confirm the device actually woke up?

Thinking Exercise

Broadcast limits

Why does a Wake-on-LAN packet usually fail across the internet?

Questions to answer:

What role does the router play?
What would port forwarding change?

The Interview Questions They Will Ask

“What is a magic packet?”
“Why does Wake-on-LAN usually require a broadcast?”
“What settings must be enabled in BIOS or OS?”
“How could you make Wake-on-LAN work remotely?”
“What are the security risks?”

Hints in Layers

Hint 1: Test with a known device Start with a device that already supports Wake-on-LAN.

Hint 2: Use broadcast IP Send to the subnet broadcast, not a unicast IP.

Hint 3: Pseudocode outline

- build magic packet: FF x6 + MAC x16
- send via UDP to broadcast
- verify device comes online

Hint 4: Verification Use ping or ARP scan to confirm device is awake.

Books That Will Help

Topic	Book	Chapter
Broadcast behavior	“Computer Networks”	Ch. 4
Ethernet framing	“TCP/IP Illustrated, Vol 1”	Ch. 2
LAN behavior	“TCP/IP Guide”	Ch. 9

Common Pitfalls and Debugging

Problem 1: “Device does not wake”

Why: BIOS or NIC settings disabled.
Fix: Enable Wake-on-LAN in BIOS and OS.
Quick test: Use vendor tools to confirm support.

Problem 2: “Packet not received”

Why: Sent to wrong broadcast address or VLAN.
Fix: Use correct subnet broadcast and ensure VLAN matches.
Quick test: Capture packets on the LAN.

Definition of Done

Sends correct magic packet
Successfully wakes a target device
Documents required device settings
Works consistently on multiple attempts

Project 16: mDNS/Bonjour Service Discovery

File: P16-mdns-service-discovery.md
Main Programming Language: Python
Alternative Programming Languages: Go, Rust, C
Coolness Level: Level 3: Genuinely Clever
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 2: Intermediate
Knowledge Area: Local Service Discovery
Software or Tool: Bonjour/mDNS
Main Book: “TCP/IP Illustrated, Vol 1” by W. Richard Stevens

What you will build: A tool that discovers local services advertised via mDNS and DNS-SD.

Why it teaches networking: It highlights multicast behavior and local naming without central servers.

Core challenges you will face:

Multicast traffic -> maps to Link Layer and LAN
DNS message parsing -> maps to Naming and Configuration Services
Noise filtering -> maps to Operations and Diagnostics

Real World Outcome

$ ./mdns_discover
Service: _airplay._tcp.local  Host: livingroom.local  Port: 7000
Service: _printer._tcp.local  Host: office-printer.local  Port: 9100
Service: _ssh._tcp.local      Host: nas.local  Port: 22

The Core Question You Are Answering

“How do devices find each other on a LAN without manual configuration?”

Concepts You Must Understand First

Multicast addresses
- How does multicast differ from broadcast?
- Book Reference: “Computer Networks” - Ch. 4
mDNS packet format
- How is it different from standard DNS?
- Book Reference: RFC 6762
Service discovery (DNS-SD)
- How are services described and announced?
- Book Reference: RFC 6763

Questions to Guide Your Design

Query strategy
- How often should you send queries without flooding?
Result caching
- How long do you keep service records?

Thinking Exercise

Service naming

Design a service record for a local file server.

Questions to answer:

What service type should you use?
What TXT records should be included?

The Interview Questions They Will Ask

“What problem does mDNS solve?”
“Why does mDNS use multicast instead of unicast?”
“What is DNS-SD and how is it related to mDNS?”
“How can mDNS traffic become a problem at scale?”
“How does service caching work in mDNS?”

Hints in Layers

Hint 1: Start by listening only Observe existing services before sending queries.

Hint 2: Use known service types Start with _ssh._tcp or _http._tcp.

Hint 3: Pseudocode outline

- join mDNS multicast group
- send query for service type
- parse responses and print instances

Hint 4: Verification Compare results with dns-sd -B _ssh._tcp (macOS) or avahi-browse (Linux).

Books That Will Help

Topic	Book	Chapter
Multicast	“Computer Networks”	Ch. 4
mDNS	RFC 6762	Spec
DNS-SD	RFC 6763	Spec

Common Pitfalls and Debugging

Problem 1: “No services found”

Why: Not joined to multicast group or wrong interface.
Fix: Verify multicast membership and interface selection.
Quick test: Use a known discovery tool and compare.

Problem 2: “Too much noise”

Why: Subnet has many mDNS speakers.
Fix: Filter by service type and suppress duplicates.
Quick test: Add a short deduplication window.

Definition of Done

Discovers at least 3 local services
Parses service name, host, and port
Handles multicast correctly
Output matches system discovery tools

Project 17: HTTP Proxy Server

File: P17-http-proxy-server.md
Main Programming Language: Python
Alternative Programming Languages: Go, Rust, C
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Proxying / Transport
Software or Tool: HTTP forward proxy
Main Book: “UNIX Network Programming, Vol 1” by W. Richard Stevens

What you will build: A forward proxy that relays HTTP requests and logs traffic metadata.

Why it teaches networking: It requires managing two TCP connections per request and handling streaming data.

Core challenges you will face:

Connection management -> maps to Transport and Ports
Request parsing -> maps to Layering and Encapsulation
Logging and policy -> maps to Operations and Security

Real World Outcome

$ ./http_proxy --listen 127.0.0.1:8081
[14:10:02] GET http://example.com/ from 192.168.1.12 -> 93.184.216.34
[14:10:03] 200 OK 1256 bytes

The Core Question You Are Answering

“How can a middlebox observe or control web traffic without breaking it?”

Concepts You Must Understand First

HTTP request structure
- How does a proxy-style request line differ?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 14
TCP stream forwarding
- How do you relay data between two sockets?
- Book Reference: “UNIX Network Programming, Vol 1” - Ch. 5
Connection lifetimes
- How do keep-alive connections change your logic?
- Book Reference: “Computer Networks” - Ch. 6

Questions to Guide Your Design

Parsing vs tunneling
- Which parts of the request should you parse vs pass through?
Logging
- What metadata is useful without capturing full content?

Thinking Exercise

CONNECT method

How does an HTTP proxy handle HTTPS via CONNECT?

Questions to answer:

What does the proxy see after the tunnel is established?
What can it not see?

The Interview Questions They Will Ask

“How does a forward proxy differ from a reverse proxy?”
“What is the CONNECT method used for?”
“How do you avoid blocking while relaying data?”
“What privacy issues do proxies raise?”
“How do proxies interact with TLS?”

Hints in Layers

Hint 1: Start with HTTP only Handle plain HTTP before adding CONNECT.

Hint 2: Use line-based parsing for headers Detect end of headers before relaying body.

Hint 3: Pseudocode outline

- accept client connection
- read request line and headers
- open connection to target server
- relay request and response
- log summary

Hint 4: Verification Set http_proxy environment variable and browse a test site.

Books That Will Help

Topic	Book	Chapter
TCP relay patterns	“UNIX Network Programming, Vol 1”	Ch. 5
HTTP format	“TCP/IP Illustrated, Vol 1”	Ch. 14
Proxy concepts	“Computer Networks”	Ch. 7

Common Pitfalls and Debugging

Problem 1: “Hangs on large responses”

Why: Not streaming data, waiting for EOF.
Fix: Relay data in chunks until Content-Length satisfied.
Quick test: Download a large file through the proxy.

Problem 2: “HTTPS fails”

Why: CONNECT not implemented or blocked.
Fix: Add CONNECT tunnel logic and allow port 443.
Quick test: Run curl -x with an HTTPS URL.

Definition of Done

Proxies HTTP requests successfully
Logs method, host, status, and byte count
Handles keep-alive safely
Optional: CONNECT tunneling works for HTTPS

Project 18: Network Topology Mapper

File: P18-network-topology-mapper.md
Main Programming Language: Python
Alternative Programming Languages: Go, Rust, C
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Discovery / Mapping
Software or Tool: Similar to nmap topology features
Main Book: “Computer Networks” by Tanenbaum and Wetherall

What you will build: A mapper that combines ARP scans, traceroute, and service probes to build a network map.

Why it teaches networking: It integrates multiple layers into a coherent picture of a real network.

Core challenges you will face:

Multi-source correlation -> maps to Operations and Diagnostics
Subnet inference -> maps to IP Addressing and Routing
Visualization -> maps to Layering and Encapsulation

Real World Outcome

$ ./netmap --subnet 192.168.1.0/24
Gateway: 192.168.1.1
Hosts: 7

Topology:
[Router]--[Switch]--(NAS)
                 |--(Printer)
                 |--(Laptop)

The Core Question You Are Answering

“How can I infer the structure of a network from observed behavior?”

Concepts You Must Understand First

ARP discovery
- How do you discover local devices reliably?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 4
Traceroute and TTL
- How can you infer hop distance?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 6
Service probing
- How do you identify devices by open ports?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 13

Questions to Guide Your Design

Data fusion
- How do you combine ARP, traceroute, and port scans?
Visualization format
- Will you output ASCII, JSON, or a graph file?

Thinking Exercise

Ambiguous topology

Two devices respond with the same hop count but different RTTs. What does that imply?

Questions to answer:

Is hop count enough to infer topology?
What additional data would help?

The Interview Questions They Will Ask

“How can you infer the existence of switches?”
“What are the limits of topology inference on a LAN?”
“How do you map devices to their roles?”
“Why is hop count not enough to determine topology?”
“What are the privacy risks of network mapping?”

Hints in Layers

Hint 1: Start with ARP inventory Build a device list before adding topology logic.

Hint 2: Add hop info Use traceroute to infer distance to router and beyond.

Hint 3: Pseudocode outline

- scan subnet for hosts
- traceroute to each host
- probe common ports
- build graph nodes and edges

Hint 4: Verification Compare your map to your actual physical layout.

Books That Will Help

Topic	Book	Chapter
ARP and LAN	“TCP/IP Illustrated, Vol 1”	Ch. 4
Routing paths	“Computer Networks”	Ch. 5
Service scanning	“TCP/IP Illustrated, Vol 1”	Ch. 13

Common Pitfalls and Debugging

Problem 1: “Topology looks flat”

Why: Insufficient data sources.
Fix: Combine ARP, traceroute, and port scans.
Quick test: Compare map before and after adding traceroute.

Problem 2: “Devices disappear”

Why: Devices sleeping or filtered.
Fix: Wake devices and increase probe retries.
Quick test: Ping devices before scanning.

Definition of Done

Discovers local hosts via ARP
Adds hop information via traceroute
Annotates devices with open ports
Produces a readable topology output

Project 19: Simple VPN Server

File: P19-simple-vpn-server.md
Main Programming Language: C
Alternative Programming Languages: Go, Rust
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: VPN / Tunneling
Software or Tool: Minimal VPN over UDP
Main Book: “UNIX Network Programming, Vol 1” by W. Richard Stevens

What you will build: A minimal VPN server that creates a secure tunnel and routes traffic through it.

Why it teaches networking: It combines transport, encryption boundaries, and routing changes in one system.

Core challenges you will face:

Tunnel interface handling -> maps to IP Addressing and Routing
Packet encapsulation -> maps to Layering and Encapsulation
Security policy -> maps to Operations and Security

Real World Outcome

$ sudo ./mini_vpn --listen 0.0.0.0:51820
Client connected: 198.51.100.22
Tunnel up: 10.8.0.2/24
Route added: 0.0.0.0/0 via tun0

The Core Question You Are Answering

“How can two networks behave as one across the public internet?”

Concepts You Must Understand First

Tunneling concepts
- How does encapsulation change routing?
- Book Reference: “Computer Networks” - Ch. 6
UDP transport
- Why do many VPNs use UDP?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 11
Route injection
- How does the client decide which traffic goes into the tunnel?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 3

Questions to Guide Your Design

Routing policy
- Will you route all traffic or only specific subnets?
Key management
- How will you provision and rotate keys securely?

Thinking Exercise

Split tunnel vs full tunnel

Which traffic should go through the VPN and why?

Questions to answer:

What are the security benefits of full tunnel?
What are the performance costs?

The Interview Questions They Will Ask

“What is the difference between site-to-site and remote access VPNs?”
“Why do VPNs often run over UDP?”
“How does a VPN change routing on the client?”
“What risks exist if DNS is not tunneled?”
“How would you troubleshoot a VPN that connects but passes no traffic?”

Hints in Layers

Hint 1: Start with a single client Keep the system simple before supporting multiple clients.

Hint 2: Use fixed IP assignments Static tunnel IPs reduce complexity initially.

Hint 3: Pseudocode outline

- read packet from tun interface
- encrypt and send over UDP
- receive UDP packet, decrypt, write to tun

Hint 4: Verification Ping a LAN host across the tunnel and capture on both ends.

Books That Will Help

Topic	Book	Chapter
Tunneling	“Computer Networks”	Ch. 6
UDP	“TCP/IP Illustrated, Vol 1”	Ch. 11
Routing	“TCP/IP Illustrated, Vol 1”	Ch. 3

Common Pitfalls and Debugging

Problem 1: “Tunnel up, no traffic”

Why: Missing routes or firewall rules.
Fix: Add explicit routes and allow UDP traffic.
Quick test: Verify routing table after connection.

Problem 2: “DNS leaks”

Why: Client still uses local DNS.
Fix: Push DNS settings through VPN configuration.
Quick test: Resolve a domain and inspect DNS server IP.

Definition of Done

Establishes a tunnel interface
Routes selected traffic through the tunnel
Passes ping and HTTP tests over the VPN
Documents key management and routing policy

Project 20: Complete Home Network Stack (Capstone)

File: P20-home-network-capstone.md
Main Programming Language: Mixed
Alternative Programming Languages: N/A
Coolness Level: Level 5: Pure Magic
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Full Stack Networking
Software or Tool: Integrated stack (router, DNS, DHCP, firewall, monitoring)
Main Book: “Computer Networks” by Tanenbaum and Wetherall

What you will build: An integrated home/office network stack that includes routing, NAT, DHCP, DNS, firewall, monitoring, and documentation.

Why it teaches networking: It forces you to connect all concepts and produce a real, observable system.

Core challenges you will face:

System integration -> maps to All Concepts
Policy design -> maps to Operations and Security
Validation and documentation -> maps to Diagnostics and Observability

Real World Outcome

$ ./stack_status
Router: online (NAT enabled)
DHCP: 12 active leases
DNS: 95% cache hit rate
Firewall: 4 rules, default deny
Monitoring: 24h bandwidth report saved

The Core Question You Are Answering

“Can I design, build, and validate a complete network from the ground up?”

Concepts You Must Understand First

End-to-end flow
- How do all layers connect from client to internet?
- Book Reference: “Computer Networks” - Ch. 1
Service dependencies
- Which services must come up first for a network to work?
- Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 18-21
Security posture
- How do you segment and protect a mixed device network?
- Book Reference: “Computer Networks” - Ch. 8

Questions to Guide Your Design

Integration order
- What is the minimal set of services for a functional network?
Validation strategy
- What tests prove each layer is working?

Thinking Exercise

Failure injection

If DNS fails but routing still works, what does the user experience?

Questions to answer:

How would you detect and isolate this failure?
What fallback can you provide?

The Interview Questions They Will Ask

“How would you design a secure home network?”
“What are the dependencies between DHCP, DNS, and routing?”
“How do you validate that NAT is working correctly?”
“What monitoring signals would you collect?”
“How would you recover from a misconfiguration?”

Hints in Layers

Hint 1: Build in layers Get routing and NAT working before services.

Hint 2: Add DHCP and DNS Validate clients can join and resolve names.

Hint 3: Pseudocode outline

- configure router and NAT
- bring up DHCP server
- bring up DNS resolver and sinkhole
- enable firewall rules
- verify with test clients

Hint 4: Verification Create a test checklist that covers link, IP, DNS, HTTP, and security.

Books That Will Help

Topic	Book	Chapter
Full stack view	“Computer Networks”	Ch. 1-8
DNS/DHCP	“TCP/IP Illustrated, Vol 1”	Ch. 18-21
Security	“Computer Networks”	Ch. 8

Common Pitfalls and Debugging

Problem 1: “Everything seems up but internet fails”

Why: NAT or DNS misconfiguration.
Fix: Validate NAT translations and DNS queries separately.
Quick test: Resolve by IP then by name.

Problem 2: “Clients join but cannot reach each other”

Why: Overly strict firewall or segmentation rules.
Fix: Add explicit allow rules for trusted subnet.
Quick test: Ping between two trusted devices.

Definition of Done

Clients obtain DHCP leases and resolve DNS
Internet access works for trusted subnet
Guest/IoT subnet is isolated by firewall
Monitoring reports bandwidth and top talkers
Documentation includes diagrams and test steps

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
1. Network Device Scanner	Level 1	Weekend	Medium	★★★☆☆
2. Build Your Own ping	Level 2	Week	Medium	★★★☆☆
3. Build Your Own traceroute	Level 2	Week	Medium	★★★☆☆
4. Packet Sniffer	Level 2	Week	High	★★★★☆
5. DNS Resolver	Level 2	Week	High	★★★★☆
6. DHCP Client	Level 2	Week	Medium	★★★☆☆
7. Simple DNS Server	Level 3	2 weeks	High	★★★★☆
8. DHCP Server	Level 3	2 weeks	High	★★★☆☆
9. Port Scanner	Level 2	Week	Medium	★★★☆☆
10. DNS Sinkhole	Level 3	2 weeks	High	★★★★☆
11. Simple HTTP Server	Level 2	Week	Medium	★★★☆☆
12. Bandwidth Monitor	Level 2	Week	Medium	★★★★☆
13. Packet Filter Firewall	Level 3	2 weeks	High	★★★★☆
14. Software Router with NAT	Level 4	3-4 weeks	Very High	★★★★★
15. Wake-on-LAN Tool	Level 1	Weekend	Low	★★☆☆☆
16. mDNS Service Discovery	Level 2	Week	Medium	★★★☆☆
17. HTTP Proxy Server	Level 3	2 weeks	High	★★★★☆
18. Network Topology Mapper	Level 3	2-3 weeks	High	★★★★☆
19. Simple VPN Server	Level 4	4 weeks	Very High	★★★★★
20. Home Network Capstone	Level 4	4-6 weeks	Very High	★★★★★

Recommendation

If you are new to networking: Start with Project 1 to build intuition about LAN discovery and ARP. If you are a systems builder: Start with Project 4 to see real traffic and build a sniffer. If you want security mastery: Start with Project 10 and Project 13 to practice DNS control and firewalling.

Final Overall Project: Integrated Home Network Stack

The Goal: Combine Projects 1, 5, 8, 13, 14, 19 into a single integrated stack that routes, protects, and monitors a real home network.

Implement routing and NAT (Project 14)
Add DHCP and DNS services (Projects 6-8 and 5)
Add firewalling and monitoring (Projects 12-13)
Secure remote access with VPN (Project 19)

Success Criteria: A client can join the network, resolve names, reach the internet, and remain isolated according to policy, with monitoring proving correct behavior.

From Learning to Production: What Is Next

Your Project	Production Equivalent	Gap to Fill
Packet Sniffer	Wireshark / tcpdump	Performance and UX polish
DNS Server	BIND / Unbound	DNSSEC, high availability
DHCP Server	ISC DHCP / dnsmasq	Lease persistence and security controls
Firewall	nftables / pf	Rule language, state scaling
Router with NAT	OpenWrt / VyOS	Hardware offload and reliability
VPN Server	WireGuard / OpenVPN	Key management, roaming support

Summary

This learning path covers home/office networking through 20 hands-on projects.

#	Project Name	Main Language	Difficulty	Time Estimate
1	Network Device Scanner	Python	Level 1	Weekend
2	Build Your Own ping	C	Level 2	Week
3	Build Your Own traceroute	C	Level 2	Week
4	Packet Sniffer	C	Level 2	Week
5	DNS Resolver	Python	Level 2	Week
6	DHCP Client	C	Level 2	Week
7	Simple DNS Server	Python	Level 3	2 weeks
8	DHCP Server	C	Level 3	2 weeks
9	Port Scanner	Python	Level 2	Week
10	DNS Sinkhole	Python	Level 3	2 weeks
11	Simple HTTP Server	Python	Level 2	Week
12	Bandwidth Monitor	Python	Level 2	Week
13	Packet Filter Firewall	C	Level 3	2 weeks
14	Software Router with NAT	C	Level 4	3-4 weeks
15	Wake-on-LAN Tool	Python	Level 1	Weekend
16	mDNS Service Discovery	Python	Level 2	Week
17	HTTP Proxy Server	Python	Level 3	2 weeks
18	Network Topology Mapper	Python	Level 3	2-3 weeks
19	Simple VPN Server	C	Level 4	4 weeks
20	Home Network Capstone	Mixed	Level 4	4-6 weeks

Expected Outcomes

You can explain and observe every layer of a home network.
You can implement and validate core services like DNS and DHCP.
You can design a secure, segmented network with monitoring.

Additional Resources and References

Standards and Specifications

Industry Analysis

Books

“Computer Networks” by Tanenbaum and Wetherall - broad conceptual base
“TCP/IP Illustrated, Vol 1” by Stevens - protocol depth
“Understanding Linux Network Internals” by Benvenuti - practical kernel-level insight