← Back to all projects

LEARN HOME OFFICE NETWORKING

Learn Home/Office Networking: From Zero to Network Engineer

Goal: Deeply understand how home and office networks work—from the physical cables to DNS resolution, DHCP leases, routing decisions, and beyond—by building real tools that exercise every concept.

Core Concept Analysis

To truly understand home/office networking, you need to grasp these fundamental building blocks:

  • MAC Addresses: Hardware identifiers for network interfaces
  • ARP (Address Resolution Protocol): Mapping IP addresses to MAC addresses
  • Ethernet Frames: The actual packets traveling on your local network
  • Switches vs Hubs: How devices communicate within a LAN

Layer 3 (Network)

  • IP Addressing: IPv4/IPv6, subnets, CIDR notation
  • Routing: How packets find their way across networks
  • ICMP: Control messages (ping, traceroute, errors)
  • NAT: How your private IPs become one public IP

Layer 4 (Transport)

  • TCP: Reliable, ordered delivery (handshakes, acknowledgments)
  • UDP: Fast, unreliable delivery (DNS, DHCP, streaming)
  • Ports: Multiplexing multiple services on one IP

Network Services

  • DNS: Translating domain names to IP addresses
  • DHCP: Automatic IP address assignment
  • Firewalls: Controlling what traffic is allowed
  • VPNs: Secure tunnels across untrusted networks

Practical Skills

  • Command-line tools: ping, traceroute, netstat, ss, ip, arp, dig, nslookup
  • Packet analysis: Understanding what’s actually on the wire
  • Troubleshooting: Diagnosing connectivity issues systematically

Project List

The projects below are ordered by increasing complexity. Each builds on concepts from previous projects.

Project 1: Network Device Scanner (ARP Discovery Tool)

  • File: LEARN_HOME_OFFICE_NETWORKING.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: Network Discovery / ARP Protocol
  • Software or Tool: Network Scanner (like arp-scan, nmap -sn)
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A command-line tool that discovers all devices on your local network by sending ARP requests and collecting responses, displaying IP addresses, MAC addresses, and (optionally) manufacturer names.

Why it teaches networking: ARP is the glue between IP addresses and physical hardware. Every time your computer talks to another device on the LAN, it first does an ARP lookup. Building this tool forces you to understand that networking isn’t magic—it’s just bytes on a wire following specific rules.

Core challenges you’ll face:

  • Sending raw ARP packets → maps to understanding Layer 2
  • Parsing ARP responses → maps to packet structure and binary parsing
  • Determining your own subnet range → maps to IP addressing and CIDR
  • Handling broadcast addresses → maps to how LANs work
  • MAC vendor lookup → maps to IEEE OUI database structure

Key Concepts:

  • ARP Protocol: “TCP/IP Illustrated, Volume 1” Chapter 4 - W. Richard Stevens
  • Ethernet Frame Structure: “Computer Networks” Chapter 4 - Andrew S. Tanenbaum
  • Python Raw Sockets: “Black Hat Python” Chapter 3 - Justin Seitz
  • Subnet Calculations: “TCP/IP Guide” Chapter 10 - Charles M. Kozierok

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic Python, understanding of what an IP address is

Real world outcome:

$ sudo ./network_scanner
Scanning 192.168.1.0/24...

IP Address       MAC Address        Vendor
-------------------------------------------------
192.168.1.1      aa:bb:cc:11:22:33  Netgear Inc.
192.168.1.15     dd:ee:ff:44:55:66  Apple Inc.
192.168.1.23     11:22:33:aa:bb:cc  Samsung Electronics
192.168.1.42     44:55:66:dd:ee:ff  Raspberry Pi Foundation

Found 4 devices in 2.3 seconds

Implementation Hints: The key insight is that ARP operates at Layer 2 (data link), below IP. You’re essentially shouting “Who has 192.168.1.X? Tell me!” to everyone on the network, and listening for responses.

Pseudo-code approach:

1. Determine local interface IP and subnet mask
2. Calculate all valid IPs in the subnet (e.g., 192.168.1.1 to 192.168.1.254)
3. For each IP:
   - Craft an ARP request packet (op=1, asking "who-has")
   - Send it as a broadcast on the local network
4. Listen for ARP replies (op=2)
5. Parse replies to extract IP and MAC address
6. Optionally: Look up MAC prefix (first 3 bytes) in OUI database

You’ll need to use either raw sockets with AF_PACKET (Linux) or a library like Scapy. The reason you need root/sudo is because you’re bypassing the normal network stack to send custom Layer 2 frames.

Learning milestones:

  1. You can see your own ARP cache (arp -a) → You understand that your OS already tracks IP-to-MAC mappings
  2. Your first ARP response comes back → You understand broadcast and how devices respond
  3. You scan your entire subnet → You understand IP ranges and CIDR notation
  4. You identify devices by vendor → You understand MAC address structure (OUI)

Project 2: Build Your Own ping Utility

  • File: LEARN_HOME_OFFICE_NETWORKING.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 Protocol / Raw Sockets
  • Software or Tool: ping utility
  • Main Book: “The Linux Programming Interface” by Michael Kerrisk

What you’ll build: A clone of the classic ping command that sends ICMP Echo Request packets to a target host and measures round-trip time, packet loss, and statistics—just like the real thing.

Why it teaches networking: ICMP is the network’s error-reporting and diagnostic protocol. Understanding it reveals how the network layer works: checksums, identification fields, sequence numbers, and why “unreachable” errors happen. You’ll also learn about raw sockets—the most fundamental way to send packets.

Core challenges you’ll face:

  • Creating raw ICMP sockets → maps to socket programming fundamentals
  • Calculating ICMP checksums → maps to how protocols ensure data integrity
  • Handling sequence numbers → maps to tracking requests/responses
  • Measuring round-trip time precisely → maps to high-resolution timing
  • Handling timeout and packet loss → maps to network unreliability

Key Concepts:

  • ICMP Protocol Specification: RFC 792 (original spec)
  • Raw Socket Programming: “Unix Network Programming, Vol 1” Chapter 28 - W. Richard Stevens
  • Internet Checksum Algorithm: “TCP/IP Illustrated, Volume 1” Chapter 3 - W. Richard Stevens
  • Network Byte Order: “Computer Systems: A Programmer’s Perspective” Chapter 11 - Bryant & O’Hallaron

Difficulty: Intermediate Time estimate: 1 week Prerequisites: C programming basics, understanding of IP addresses

Real world outcome:

$ sudo ./myping google.com
PING google.com (142.250.80.46): 56 data bytes
64 bytes from 142.250.80.46: icmp_seq=0 ttl=117 time=14.2 ms
64 bytes from 142.250.80.46: icmp_seq=1 ttl=117 time=13.8 ms
64 bytes from 142.250.80.46: icmp_seq=2 ttl=117 time=15.1 ms
64 bytes from 142.250.80.46: icmp_seq=3 ttl=117 time=14.0 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.8/14.3/15.1/0.5 ms

Implementation Hints: ICMP Echo Request has this structure:

Type (1 byte): 8 (for Echo Request)
Code (1 byte): 0
Checksum (2 bytes): calculated over entire message
Identifier (2 bytes): to match requests with replies
Sequence (2 bytes): incremented for each ping
Payload (variable): typically 56 bytes of data

Pseudo-code approach:

1. Create raw socket: socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)
2. Resolve hostname to IP address using getaddrinfo()
3. Loop:
   a. Build ICMP Echo Request packet
   b. Calculate checksum (one's complement sum)
   c. Record current timestamp
   d. Send packet with sendto()
   e. Wait for reply with recvfrom() (with timeout)
   f. If reply received:
      - Parse ICMP header
      - Verify type=0 (Echo Reply) and identifier matches
      - Calculate round-trip time
      - Print results
   g. Sleep 1 second before next ping
4. On Ctrl+C: print statistics

The checksum algorithm is the tricky part: sum all 16-bit words, add any carry bits back, then take the one’s complement.

Learning milestones:

  1. You successfully send an ICMP packet → You understand raw sockets
  2. You receive a reply and parse it → You understand ICMP message structure
  3. Your timings match the real ping → You understand precise timing in network code
  4. You handle timeouts gracefully → You understand network unreliability

Project 3: Build Your Own traceroute Utility

  • File: LEARN_HOME_OFFICE_NETWORKING.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 / TTL / Network Hops
  • Software or Tool: traceroute/tracert utility
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A clone of traceroute that shows the path packets take from your computer to a destination, revealing every router hop along the way with timing information.

Why it teaches networking: TTL (Time To Live) is the mechanism that prevents packets from looping forever. By exploiting TTL expiration, traceroute forces each router to reveal itself. This teaches you how routing actually works—packets don’t magically appear at their destination; they hop through multiple routers, each making independent forwarding decisions.

Core challenges you’ll face:

  • Manipulating IP TTL field → maps to understanding IP header structure
  • Receiving ICMP Time Exceeded messages → maps to ICMP error messages
  • Sending UDP probes (or ICMP) → maps to protocol differences
  • Handling multiple probes per hop → maps to reliability and timing variance
  • Reverse DNS lookup for router IPs → maps to DNS integration

Key Concepts:

  • TTL and Routing: “TCP/IP Illustrated, Volume 1” Chapter 8 - W. Richard Stevens
  • ICMP Time Exceeded: RFC 792, Type 11
  • UDP vs ICMP Traceroute: “Computer Networks” Chapter 5 - Tanenbaum & Wetherall
  • Path MTU Discovery: “TCP/IP Guide” Chapter 43 - Charles M. Kozierok

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Understanding of ping (Project 2), basic routing concepts

Real world outcome:

$ sudo ./mytraceroute google.com
traceroute to google.com (142.250.80.46), 30 hops max
 1  192.168.1.1 (192.168.1.1)  1.234 ms  1.156 ms  1.089 ms
 2  10.0.0.1 (10.0.0.1)  12.456 ms  11.234 ms  12.890 ms
 3  isp-router.example.com (203.0.113.1)  15.234 ms  14.567 ms  15.890 ms
 4  * * *
 5  72.14.215.85 (72.14.215.85)  18.234 ms  17.890 ms  18.456 ms
 6  142.250.80.46 (142.250.80.46)  14.234 ms  13.890 ms  14.123 ms

Implementation Hints: The key insight is TTL manipulation:

  • Set TTL=1: First router decrements to 0, sends back “Time Exceeded”
  • Set TTL=2: Second router decrements to 0, sends back “Time Exceeded”
  • Continue until you reach the destination

Pseudo-code approach:

1. Create two sockets:
   - Raw socket to receive ICMP errors
   - UDP socket to send probes (or raw ICMP socket)
2. For each TTL from 1 to max_hops:
   a. Set socket option IP_TTL to current TTL value
   b. Send 3 probes (to handle packet loss)
   c. For each probe:
      - Send UDP packet to high port (33434+) or ICMP Echo Request
      - Record send time
      - Wait for ICMP response (Time Exceeded or Echo Reply)
      - Calculate RTT
   d. Extract router IP from ICMP error message
   e. Optionally: reverse DNS lookup on router IP
   f. Print hop line
   g. If received ICMP Echo Reply (or Port Unreachable for UDP), we've reached destination

The difference between Unix traceroute (UDP) and Windows tracert (ICMP) is historical. Some firewalls block one but not the other.

Learning milestones:

  1. First hop (your router) responds → You understand TTL decrement behavior
  2. You see your ISP’s routers → You understand your packets leave your network
  3. You handle non-responsive hops (asterisks) → You understand routers can drop ICMP
  4. You trace to any internet destination → You understand global routing

Project 4: Network Packet Sniffer

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C
  • Alternative Programming Languages: Python, Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Raw Sockets / Protocol Parsing
  • Software or Tool: Wireshark/tcpdump clone
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A packet capture tool that shows all network traffic on your interface—every Ethernet frame, IP packet, and TCP/UDP segment—with human-readable protocol decoding.

Why it teaches networking: This is the ultimate networking learning project. You will see exactly what travels on the wire. You’ll parse Ethernet headers (6+6+2 bytes), IP headers (20+ bytes), TCP/UDP headers, and understand every field. After building this, protocols stop being abstract—they’re just bytes in specific positions.

Core challenges you’ll face:

  • Capturing raw Ethernet frames → maps to Layer 2 understanding
  • Parsing binary protocol headers → maps to struct packing, endianness
  • Decoding multiple protocols (IP, TCP, UDP, ICMP, ARP) → maps to OSI layers in practice
  • Handling promiscuous mode → maps to how network cards work
  • Filtering packets efficiently → maps to BPF (Berkeley Packet Filter)

Key Concepts:

  • Ethernet Frame Format: “Computer Networks” Chapter 4 - Tanenbaum & Wetherall
  • IP Header Structure: “TCP/IP Illustrated, Volume 1” Chapter 3 - W. Richard Stevens
  • TCP Header and State Machine: “TCP/IP Illustrated, Volume 1” Chapter 17 - W. Richard Stevens
  • Raw Socket Programming: “Linux Socket Programming” Chapter 15 - Warren W. Gay
  • BPF Filtering: “The Linux Programming Interface” Chapter 61 - Michael Kerrisk

Resources for key challenges:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Strong C skills, understanding of binary/hex, Projects 1-3 completed

Real world outcome:

$ sudo ./mysniff eth0
Sniffing on eth0...

[1] ETH  src=aa:bb:cc:11:22:33 dst=dd:ee:ff:44:55:66 type=0x0800 (IPv4)
    IP   src=192.168.1.100 dst=142.250.80.46 proto=TCP ttl=64
    TCP  src_port=54321 dst_port=443 seq=1234567 ack=7654321 flags=[SYN,ACK]

[2] ETH  src=dd:ee:ff:44:55:66 dst=aa:bb:cc:11:22:33 type=0x0806 (ARP)
    ARP  op=REQUEST who-has 192.168.1.1? tell 192.168.1.100

[3] ETH  src=aa:bb:cc:11:22:33 dst=dd:ee:ff:44:55:66 type=0x0800 (IPv4)
    IP   src=192.168.1.100 dst=8.8.8.8 proto=UDP ttl=64
    UDP  src_port=12345 dst_port=53 len=45
    DNS  Query: www.example.com A?

Implementation Hints: The Ethernet frame structure is:

Destination MAC (6 bytes)
Source MAC (6 bytes)
EtherType (2 bytes): 0x0800=IPv4, 0x0806=ARP, 0x86DD=IPv6
Payload (46-1500 bytes)

Pseudo-code approach:

1. Create raw socket: socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL))
2. Optionally: Set interface to promiscuous mode (sees all traffic, not just yours)
3. Loop forever:
   a. Receive packet with recvfrom()
   b. Parse Ethernet header (first 14 bytes)
   c. Based on EtherType:
      - 0x0800: Parse IP header, then TCP/UDP/ICMP
      - 0x0806: Parse ARP packet
   d. Print decoded information

For parsing, use C structs with __attribute__((packed)) or manual byte extraction. Be careful with endianness—network byte order is big-endian, but your CPU is likely little-endian.

Learning milestones:

  1. You see raw hex bytes → You understand that networking is just bytes
  2. You decode Ethernet headers → You understand Layer 2
  3. You decode IP and TCP headers → You understand Layers 3 and 4
  4. You see DNS queries/responses → You understand application protocols ride on top of transport

Project 5: DNS Resolver (Client-Side)

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: C, Go, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: DNS Protocol / UDP
  • Software or Tool: dig/nslookup clone
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A DNS resolver that can query DNS servers directly, parse responses, and perform recursive lookups—starting from root servers if needed—just like your OS does when you type a URL.

Why it teaches networking: DNS is the phone book of the internet. Every website visit starts with a DNS lookup. Understanding DNS means understanding how distributed systems work: caching, TTLs, delegation, recursion. After building this, you’ll never wonder “why can’t I reach that website?” again—you’ll know exactly where to look.

Core challenges you’ll face:

  • Constructing DNS query packets → maps to binary protocol encoding
  • Parsing DNS response packets → maps to variable-length records and compression
  • Understanding DNS record types → maps to A, AAAA, CNAME, MX, NS, etc.
  • Implementing recursive resolution → maps to how resolvers actually work
  • Handling UDP message limits → maps to why DNS sometimes uses TCP

Key Concepts:

  • DNS Message Format: RFC 1035 (the original DNS spec)
  • DNS Record Types: “TCP/IP Guide” Chapter 57 - Charles M. Kozierok
  • Recursive vs Iterative Resolution: “TCP/IP Illustrated, Volume 1” Chapter 14 - W. Richard Stevens
  • DNS Compression: “DNS and BIND” Chapter 15 - Paul Albitz & Cricket Liu

Resources for key challenges:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Basic understanding of UDP, binary data handling

Real world outcome:

$ ./mydns google.com
Querying 8.8.8.8 for google.com...

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             299     IN      A       142.250.80.46
google.com.             299     IN      A       142.250.80.47
google.com.             299     IN      A       142.250.80.78

Query time: 14 ms
Server: 8.8.8.8#53

$ ./mydns --trace google.com
Tracing from root servers...
[root] . -> a.root-servers.net (198.41.0.4)
[TLD] com. -> a.gtld-servers.net (192.5.6.30)
[AUTH] google.com. -> ns1.google.com (216.239.32.10)
[FINAL] google.com. A = 142.250.80.46

Total queries: 4

Implementation Hints: DNS uses a specific binary format. The header is 12 bytes, followed by the question section, then answer records.

Pseudo-code for simple resolver:

1. Build DNS query:
   - Header: ID, flags (recursion desired), question count=1
   - Question: domain name (length-prefixed labels), type=A, class=IN
2. Send UDP packet to DNS server (e.g., 8.8.8.8:53)
3. Receive response
4. Parse header (check response code)
5. Skip question section
6. Parse answer section:
   - For each record: parse name, type, class, TTL, data length, data
   - Handle name compression (pointers with 0xC0 prefix)
7. Print results

For recursive resolution from root servers, you follow the chain of NS records until you reach an authoritative answer.

Learning milestones:

  1. You query 8.8.8.8 and get a response → You understand basic DNS
  2. You parse A records correctly → You understand DNS message format
  3. You handle CNAME chains → You understand DNS indirection
  4. You resolve from root servers → You understand the full DNS hierarchy

Project 6: DHCP Client

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C
  • Alternative Programming Languages: Python, Go
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DHCP Protocol / Broadcast
  • Software or Tool: dhclient clone
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A DHCP client that can obtain an IP address, subnet mask, gateway, and DNS servers from a DHCP server—the same process that happens when your computer connects to any network.

Why it teaches networking: DHCP is how devices automatically configure themselves on a network. Understanding DHCP means understanding broadcast, lease management, and the “bootstrap problem” (how do you talk on a network before you have an IP address?). This is essential knowledge for troubleshooting “can’t get an IP” issues.

Core challenges you’ll face:

  • Sending broadcast packets before having an IP → maps to 0.0.0.0 source address, 255.255.255.255 destination
  • Understanding the DORA sequence → maps to Discover, Offer, Request, Acknowledge
  • Parsing DHCP options → maps to TLV (Type-Length-Value) encoding
  • Managing leases and renewals → maps to state machine design
  • Binding raw sockets to port 68 → maps to privileged network operations

Key Concepts:

  • DHCP Protocol: RFC 2131 (Dynamic Host Configuration Protocol)
  • DHCP Options: RFC 2132 (defines option codes)
  • Broadcast Networking: “TCP/IP Illustrated, Volume 1” Chapter 12 - W. Richard Stevens
  • DHCP State Machine: “TCP/IP Guide” Chapter 33 - Charles M. Kozierok

Resources for key challenges:

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Understanding of UDP, raw sockets, binary parsing

Real world outcome:

$ sudo ./mydhclient eth0
DHCP Client starting on eth0...

[DISCOVER] Broadcasting DHCP Discover...
[OFFER] Received offer from 192.168.1.1:
  - Offered IP: 192.168.1.105
  - Lease time: 86400 seconds

[REQUEST] Requesting 192.168.1.105...
[ACK] Lease acknowledged!

Configuration received:
  IP Address:    192.168.1.105
  Subnet Mask:   255.255.255.0
  Gateway:       192.168.1.1
  DNS Servers:   8.8.8.8, 8.8.4.4
  Lease Time:    86400 seconds (24 hours)

Interface configured. Lease expires in 24 hours.

Implementation Hints: DHCP uses UDP ports 67 (server) and 68 (client). The “DORA” handshake:

  1. Discover: Client broadcasts “I need an IP” (src=0.0.0.0, dst=255.255.255.255)
  2. Offer: Server responds with an available IP
  3. Request: Client broadcasts “I want that IP” (in case multiple servers offered)
  4. Acknowledge: Server confirms the lease

Pseudo-code approach:

1. Create raw socket bound to UDP port 68
2. Set socket options for broadcast
3. Build DHCP Discover packet:
   - BOOTP header (op=1, htype=1, hlen=6, xid=random, etc.)
   - DHCP magic cookie (99.130.83.99)
   - Option 53: DHCP Message Type = Discover
   - Option 55: Parameter Request List (subnet, router, DNS, etc.)
   - Option 255: End
4. Broadcast to 255.255.255.255:67
5. Receive Offer on port 68
6. Parse offered IP and options
7. Build DHCP Request packet (include server ID, requested IP)
8. Broadcast Request
9. Receive ACK
10. Configure interface with received parameters

The trickiest part is sending from 0.0.0.0—you don’t have an IP yet, so you can’t use normal sockets.

Learning milestones:

  1. You capture a DHCP exchange with Wireshark → You understand what you’re implementing
  2. Your Discover reaches the server → You understand broadcast
  3. You receive and parse an Offer → You understand DHCP options
  4. You complete the full DORA sequence → You can get an IP from any DHCP server

Project 7: Simple DNS Server

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: C, Go, Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DNS Server / Zone Files
  • Software or Tool: BIND/dnsmasq clone
  • Main Book: “DNS and BIND” by Paul Albitz & Cricket Liu

What you’ll build: A DNS server that can answer queries for your own domain zones, cache results from upstream servers, and act as the DNS resolver for your entire home network.

Why it teaches networking: Running your own DNS server teaches you both sides of the conversation. You’ll implement zone files, understand TTLs from the server’s perspective, handle multiple record types, and see exactly why DNS behaves the way it does. This is foundational for understanding Pi-hole, internal company DNS, and DNS-based load balancing.

Core challenges you’ll face:

  • Parsing incoming DNS queries → maps to understanding client needs
  • Managing zone data → maps to authoritative vs recursive
  • Implementing caching with TTL → maps to performance optimization
  • Forwarding to upstream servers → maps to recursive resolution
  • Handling concurrent queries → maps to async/threading in network services

Key Concepts:

  • DNS Zone Files: “DNS and BIND” Chapter 4 - Albitz & Liu
  • Authoritative vs Recursive: “TCP/IP Guide” Chapter 57 - Charles M. Kozierok
  • DNS Caching: “DNS and BIND” Chapter 5 - Albitz & Liu
  • Concurrent UDP Servers: “Unix Network Programming, Vol 1” Chapter 8 - W. Richard Stevens

Resources for key challenges:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Project 5 (DNS Resolver), understanding of UDP servers

Real world outcome:

$ ./mydns-server --zone mylab.local --upstream 8.8.8.8
DNS Server listening on port 53...
Loaded zone: mylab.local (3 records)

# From another terminal:
$ dig @localhost server1.mylab.local
;; ANSWER SECTION:
server1.mylab.local.    300     IN      A       192.168.1.10

$ dig @localhost google.com
;; ANSWER SECTION:
google.com.             299     IN      A       142.250.80.46
(cached from upstream)

# Server log:
[QUERY] server1.mylab.local A from 127.0.0.1 -> LOCAL ZONE
[QUERY] google.com A from 127.0.0.1 -> FORWARD to 8.8.8.8
[CACHE] google.com A TTL=299

Implementation Hints: A DNS server handles two types of requests:

  1. Authoritative: “I own this zone, here’s the answer”
  2. Recursive: “I’ll ask someone else and cache the result”

Pseudo-code approach:

1. Load zone files into memory (domain -> {type -> [records]})
2. Create UDP socket bound to port 53
3. Loop forever:
   a. Receive DNS query
   b. Parse query (extract domain name, record type)
   c. If domain is in our zones:
      - Build response from local data
   d. Else if caching enabled:
      - Check cache (if present and not expired, use it)
      - Otherwise, forward to upstream server
      - Cache the response with TTL
   e. Send response back to client

Zone file format (simplified):

; mylab.local zone
server1   A     192.168.1.10
server2   A     192.168.1.11
www       CNAME server1

Learning milestones:

  1. Your server responds to dig queries → You understand DNS server basics
  2. Local zone lookups work → You understand authoritative DNS
  3. Forwarded queries return results → You understand recursive resolution
  4. Cache reduces upstream queries → You understand DNS caching and TTL

Project 8: DHCP Server

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C
  • Alternative Programming Languages: Python, Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DHCP Server / IP Pool Management
  • Software or Tool: ISC DHCP/dnsmasq clone
  • Main Book: “TCP/IP Guide” by Charles M. Kozierok

What you’ll build: A DHCP server that manages an IP address pool, hands out addresses to clients, tracks leases, and provides network configuration (gateway, DNS, etc.) to any device that connects.

Why it teaches networking: The DHCP server is the authority that decides who gets what IP. Building one teaches you about IP pool management, lease tracking, and the challenges of running network infrastructure. You’ll understand why sometimes devices get the same IP and sometimes they don’t.

Core challenges you’ll face:

  • Managing an IP address pool → maps to resource allocation
  • Tracking leases and expirations → maps to state management
  • Handling the DORA sequence from server side → maps to protocol implementation
  • Sending broadcast responses → maps to replying to clients without IPs
  • Persistence across restarts → maps to reliable network services

Key Concepts:

  • DHCP Server Operation: RFC 2131 Section 4
  • Lease Database Management: “TCP/IP Guide” Chapter 33 - Charles M. Kozierok
  • BOOTP Relay: “TCP/IP Illustrated, Volume 1” Chapter 16 - W. Richard Stevens
  • Broadcast Response: RFC 2131 Section 4.1

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Project 6 (DHCP Client), understanding of network services

Real world outcome:

$ sudo ./mydhcp-server --interface eth0 --pool 192.168.1.100-192.168.1.200 \
    --gateway 192.168.1.1 --dns 8.8.8.8,8.8.4.4 --lease-time 3600
DHCP Server starting on eth0...
Pool: 192.168.1.100 - 192.168.1.200 (101 addresses)

[DISCOVER] from aa:bb:cc:11:22:33 (no hostname)
[OFFER] 192.168.1.100 to aa:bb:cc:11:22:33
[REQUEST] aa:bb:cc:11:22:33 requests 192.168.1.100
[ACK] Leased 192.168.1.100 to aa:bb:cc:11:22:33 for 3600s

[DISCOVER] from dd:ee:ff:44:55:66 (hostname: raspberrypi)
[OFFER] 192.168.1.101 to dd:ee:ff:44:55:66
[REQUEST] dd:ee:ff:44:55:66 requests 192.168.1.101
[ACK] Leased 192.168.1.101 to dd:ee:ff:44:55:66 for 3600s

Active leases:
  192.168.1.100 -> aa:bb:cc:11:22:33 (expires in 3542s)
  192.168.1.101 -> dd:ee:ff:44:55:66 (expires in 3598s)

Implementation Hints: The DHCP server maintains several data structures:

  • Address pool: Available IPs to hand out
  • Lease table: MAC address -> {IP, lease_start, lease_duration}
  • Reservations: Static MAC -> IP mappings (optional)

Pseudo-code approach:

1. Parse configuration (pool range, options, lease time)
2. Load existing leases from disk (if any)
3. Create raw socket on UDP port 67
4. Loop forever:
   a. Receive DHCP message
   b. Parse message (extract MAC, message type, requested IP, etc.)
   c. Switch on message type:
      - DISCOVER:
         * Find available IP (prefer previously leased to this MAC)
         * Send OFFER with that IP and options
      - REQUEST:
         * Verify requested IP is available or already leased to this MAC
         * If valid: mark lease active, send ACK
         * If invalid: send NAK
      - RELEASE:
         * Remove lease, return IP to pool
   d. Periodically: expire old leases
5. On shutdown: save leases to disk

Learning milestones:

  1. You receive DISCOVER and send OFFER → You understand server-side DHCP
  2. A real device gets an IP from your server → You’re running network infrastructure
  3. Multiple devices get unique IPs → You understand pool management
  4. Leases persist across server restarts → You understand reliable services

Project 9: Port Scanner

  • File: LEARN_HOME_OFFICE_NETWORKING.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: TCP Handshake / Service Discovery
  • Software or Tool: nmap clone (basic)
  • Main Book: “Nmap Network Scanning” by Gordon “Fyodor” Lyon

What you’ll build: A TCP port scanner that can quickly identify which ports are open on a target host, what services might be running, and (optionally) perform basic banner grabbing to identify software versions.

Why it teaches networking: Port scanning teaches you about the TCP three-way handshake (SYN, SYN-ACK, ACK), connection states, and how services listen on ports. You’ll understand why firewalls matter, what “filtered” vs “closed” means, and how network services expose themselves.

Core challenges you’ll face:

  • TCP connect scanning → maps to full handshake, easy to detect
  • SYN scanning (half-open) → maps to raw sockets, stealthier
  • Parallel scanning for speed → maps to async I/O or threading
  • Timeout handling → maps to distinguishing closed from filtered
  • Banner grabbing → maps to application-layer protocols

Key Concepts:

  • TCP State Machine: “TCP/IP Illustrated, Volume 1” Chapter 17 - W. Richard Stevens
  • Port Scanning Techniques: “Nmap Network Scanning” Chapter 5 - Fyodor
  • Service Fingerprinting: “Nmap Network Scanning” Chapter 7 - Fyodor
  • Async I/O in Python: “Fluent Python” Chapter 21 - Luciano Ramalho

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic understanding of TCP, socket programming

Real world outcome:

$ ./myportscan 192.168.1.1 --ports 1-1000 --threads 50
Scanning 192.168.1.1...

PORT      STATE   SERVICE     BANNER
22/tcp    open    ssh         SSH-2.0-OpenSSH_8.4
53/tcp    open    domain
80/tcp    open    http        nginx/1.18.0
443/tcp   open    https
631/tcp   closed  ipp

Scan completed in 4.2 seconds
995 closed ports not shown

Implementation Hints: For a basic connect scan, you just attempt a TCP connection to each port. If it succeeds, the port is open. If it fails with “connection refused,” it’s closed. If it times out, it’s filtered.

Pseudo-code approach:

1. Parse target host and port range
2. Create a thread pool or async executor
3. For each port in range:
   a. Schedule a connection attempt:
      - Create TCP socket
      - Set timeout (e.g., 1 second)
      - Try to connect
      - If success: port is open, optionally grab banner
      - If refused: port is closed
      - If timeout: port is filtered
4. Collect results
5. Print open ports with service names (from well-known port list)

For SYN scanning (requires root), you send a SYN packet and look for SYN-ACK (open) or RST (closed) without completing the handshake.

Banner grabbing: After connecting, receive a few bytes—many services send a greeting (SSH version, HTTP server, SMTP banner, etc.).

Learning milestones:

  1. You detect open ports on localhost → You understand TCP connections
  2. You scan remote hosts → You understand network reachability
  3. You grab service banners → You understand application protocols
  4. You scan 1000 ports in under 5 seconds → You understand concurrent network I/O

Project 10: DNS Sinkhole (Pi-hole Clone)

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DNS Filtering / Ad Blocking
  • Software or Tool: Pi-hole clone
  • Main Book: “DNS and BIND” by Paul Albitz & Cricket Liu

What you’ll build: A DNS server that blocks ads and trackers by returning empty responses for blacklisted domains while forwarding legitimate queries to upstream servers—protecting your entire network.

Why it teaches networking: Pi-hole is the perfect example of “controlling the network at a chokepoint.” By owning DNS, you control what domains can be resolved. This teaches you about DNS as infrastructure, blacklist management, and why DNS is often the first thing attackers target.

Core challenges you’ll face:

  • Efficient blocklist matching → maps to data structures for fast lookup
  • Returning sinkhole responses → maps to DNS response crafting
  • Logging and statistics → maps to observability
  • Updating blocklists → maps to external data integration
  • Allowlist overrides → maps to exception handling

Key Concepts:

Resources for key challenges:

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Project 7 (DNS Server)

Real world outcome:

$ sudo ./mysinkhole --upstream 8.8.8.8 --blocklist blocklists.txt --port 53
DNS Sinkhole starting...
Loaded 150,000 blocked domains from 5 lists
Listening on port 53

# From any device on your network (after setting this as DNS):
$ curl ads.example.com
# Times out - domain is blocked!

$ curl google.com
# Works normally

# Server log:
[BLOCKED] ads.example.com from 192.168.1.100 -> 0.0.0.0
[BLOCKED] tracker.analytics.com from 192.168.1.100 -> 0.0.0.0
[FORWARD] google.com from 192.168.1.100 -> 8.8.8.8

Stats (last hour):
  Total queries:    1,234
  Blocked:          456 (37%)
  Forwarded:        778
  Top blocked:      ads.google.com (89 hits)

Implementation Hints: The core idea is simple: intercept DNS queries, check if the domain is blacklisted, and either return 0.0.0.0 (blocked) or forward to a real DNS server.

Pseudo-code approach:

1. Load blocklists into a set (fast O(1) lookup)
   - Handle wildcards: *.ads.example.com
2. Start DNS server on port 53
3. For each query:
   a. Check if domain (or any parent) is in blocklist
   b. If blocked:
      - Log the block
      - Return DNS response with A=0.0.0.0 (or NXDOMAIN)
   c. If allowed:
      - Forward to upstream DNS
      - Cache response
      - Return to client
4. Maintain statistics: queries/hour, top blocked domains, etc.
5. Periodically: Update blocklists from remote sources

For blocklist matching with wildcards, you might need a trie structure or just check each domain level: foo.ads.example.com, ads.example.com, example.com.

Learning milestones:

  1. You block one hardcoded domain → You understand the sinkhole concept
  2. You load real blocklists → You understand list management
  3. Ads disappear from your browser → You’re running network-wide ad blocking
  4. You see statistics on blocked queries → You understand network observability

Project 11: Simple HTTP Server

  • File: LEARN_HOME_OFFICE_NETWORKING.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: HTTP Protocol / TCP Sockets
  • Software or Tool: nginx/Apache clone (basic)
  • Main Book: “HTTP: The Definitive Guide” by David Gourley & Brian Totty

What you’ll build: An HTTP/1.1 server that can serve static files, handle multiple concurrent connections, parse HTTP headers, and return proper status codes—a mini web server you actually understand.

Why it teaches networking: HTTP is the protocol you use most but probably understand least. Building a server teaches you about TCP connection handling, the request/response model, status codes, headers, content types, and why web servers are configured the way they are. This is the foundation for understanding REST APIs, web security, and everything browser-related.

Core challenges you’ll face:

  • Parsing HTTP requests → maps to text protocol parsing
  • Serving files securely → maps to path traversal prevention
  • Handling concurrent connections → maps to threading, select, or async
  • Correct Content-Type headers → maps to MIME types
  • HTTP/1.1 keep-alive → maps to connection reuse

Key Concepts:

  • HTTP/1.1 Specification: RFC 2616 (or updated RFC 7230-7235)
  • TCP Server Design: “Unix Network Programming, Vol 1” Chapter 5 - W. Richard Stevens
  • Concurrent Server Models: “The Linux Programming Interface” Chapter 60 - Michael Kerrisk
  • HTTP Security: “The Web Application Hacker’s Handbook” Chapter 3 - Stuttard & Pinto

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: TCP socket programming, basic understanding of HTTP

Real world outcome:

$ ./myhttp --port 8080 --root ./public
HTTP Server listening on port 8080
Serving files from ./public

# From browser or curl:
$ curl http://localhost:8080/index.html
<!DOCTYPE html>
<html>
<head><title>My Server Works!</title></head>
...

$ curl -I http://localhost:8080/style.css
HTTP/1.1 200 OK
Content-Type: text/css
Content-Length: 1234
Connection: keep-alive

$ curl http://localhost:8080/../../../etc/passwd
HTTP/1.1 403 Forbidden
# Path traversal blocked!

# Server log:
[200] GET /index.html - 192.168.1.100 - 2ms
[200] GET /style.css - 192.168.1.100 - 1ms
[403] GET /../../../etc/passwd - 192.168.1.100 - 0ms (blocked)
[404] GET /nonexistent.html - 192.168.1.100 - 0ms

Implementation Hints: HTTP/1.1 request format:

GET /path/to/file HTTP/1.1\r\n
Host: localhost:8080\r\n
User-Agent: curl/7.68.0\r\n
\r\n

Pseudo-code approach:

1. Create TCP socket, bind to port, listen
2. Loop:
   a. Accept new connection
   b. Spawn thread/process or add to async loop
3. Per connection:
   a. Read until \r\n\r\n (end of headers)
   b. Parse first line: method, path, version
   c. Parse headers into key-value map
   d. Normalize path (resolve .., prevent traversal)
   e. If path is directory, look for index.html
   f. If file exists:
      - Read file
      - Determine Content-Type from extension
      - Send: "HTTP/1.1 200 OK\r\n" + headers + "\r\n" + body
   g. If file doesn't exist:
      - Send: "HTTP/1.1 404 Not Found\r\n" + error page
   h. If keep-alive, loop back to (a); else close

Security critical: ../ path traversal. Normalize the path and ensure it stays within the document root.

Learning milestones:

  1. You serve a single file → You understand HTTP basics
  2. Multiple files with correct MIME types → You understand Content-Type
  3. Concurrent connections work → You understand server scaling
  4. Path traversal is blocked → You understand web security basics

Project 12: Bandwidth Monitor

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Network Monitoring / Traffic Analysis
  • Software or Tool: nethogs/iftop clone
  • Main Book: “The Practice of Network Security Monitoring” by Richard Bejtlich

What you’ll build: A real-time bandwidth monitor that shows per-process or per-connection network usage, tracks historical data, and helps you identify what’s eating your bandwidth.

Why it teaches networking: Understanding network traffic patterns is essential for troubleshooting. Building a monitor teaches you about /proc/net interfaces, connection tracking, and how to correlate network activity with processes. You’ll learn why your internet feels slow and which app is the culprit.

Core challenges you’ll face:

  • Reading network statistics from /proc → maps to Linux internals
  • Correlating connections to processes → maps to /proc/fd and socket inodes
  • Calculating real-time rates → maps to delta calculations and sampling
  • Terminal UI → maps to curses/ncurses
  • Historical data storage → maps to time-series basics

Key Concepts:

  • /proc/net Files: “The Linux Programming Interface” Chapter 12 - Michael Kerrisk
  • Socket to Process Mapping: “Linux System Programming” Chapter 5 - Robert Love
  • Terminal UI: “ncurses Programming HOWTO” - Linux Documentation Project
  • Rate Calculation: Simple calculus (Δbytes / Δtime)

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic Python, understanding of network connections

Real world outcome:

$ sudo ./mybandwidth
Network Bandwidth Monitor - Press 'q' to quit

Interface: eth0
  Total RX: 1.23 GB   TX: 456 MB
  Current:  ↓ 2.3 MB/s   ↑ 124 KB/s

Process              PID    RX Rate    TX Rate   Total
─────────────────────────────────────────────────────────
firefox             1234    1.8 MB/s   45 KB/s   892 MB
spotify             5678    450 KB/s   12 KB/s   234 MB
dropbox             9012    23 KB/s    67 KB/s   156 MB
sshd                3456    5 KB/s     8 KB/s    12 MB

Top connections:
  192.168.1.100:54321 ↔ 151.101.1.69:443 (reddit)  1.2 MB/s
  192.168.1.100:54322 ↔ 35.186.224.25:443 (spotify) 420 KB/s

Implementation Hints: On Linux, you can get network statistics from:

  • /proc/net/dev - Per-interface byte/packet counts
  • /proc/net/tcp and /proc/net/udp - Active connections with inode numbers
  • /proc/[pid]/fd/ - File descriptors, some are sockets
  • /proc/[pid]/net/ - Per-process network info

Pseudo-code approach:

1. Read initial byte counts from /proc/net/dev
2. Build mapping: socket_inode -> (pid, process_name)
   - For each /proc/[pid]/fd/*, readlink to get socket:[inode]
3. Build mapping: connection -> socket_inode
   - Parse /proc/net/tcp and /proc/net/udp
4. Loop every 1 second:
   a. Read current byte counts
   b. Calculate delta (current - previous)
   c. For each connection, attribute bytes to process
   d. Update terminal display
   e. Store previous = current

The trickiest part is correlating sockets to processes—Linux doesn’t make this easy, which is why tools like nethogs exist.

Learning milestones:

  1. You read interface statistics → You understand /proc/net/dev
  2. You calculate bytes/second → You understand rate measurement
  3. You correlate connections to processes → You understand Linux socket internals
  4. Real-time updating works → You understand terminal UI programming

Project 13: Simple Packet Filter Firewall

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C
  • Alternative Programming Languages: Python (with nftables bindings), Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Netfilter / Packet Filtering
  • Software or Tool: iptables/nftables clone
  • Main Book: “Linux Firewalls” by Steve Suehring

What you’ll build: A user-space packet filter that can block or allow traffic based on rules (source/dest IP, port, protocol), with logging capabilities—understanding how iptables works under the hood.

Why it teaches networking: Firewalls are the gatekeepers of networks. Building one teaches you about the kernel’s netfilter framework, packet inspection, rule matching, and the difference between stateless and stateful filtering. You’ll understand why certain traffic is blocked and how to troubleshoot firewall issues.

Core challenges you’ll face:

  • Using netfilter queues (NFQUEUE) → maps to kernel-userspace communication
  • Parsing packet headers → maps to IP, TCP, UDP structure
  • Rule matching efficiently → maps to pattern matching algorithms
  • Stateful connection tracking → maps to maintaining connection state
  • Logging and verdict decisions → maps to accept/drop/reject

Key Concepts:

  • Netfilter Architecture: “Linux Firewalls” Chapter 2 - Steve Suehring
  • iptables Tables and Chains: “Linux Firewalls” Chapter 4 - Steve Suehring
  • Connection Tracking: “Understanding Linux Network Internals” Chapter 20 - Christian Benvenuti
  • NFQUEUE Usage: libnetfilter_queue documentation

Resources for key challenges:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Project 4 (Packet Sniffer), understanding of iptables basics

Real world outcome:

$ sudo ./myfirewall --config rules.conf
Firewall starting with 5 rules loaded...

Rules:
  1. ALLOW tcp dst 22 (SSH)
  2. ALLOW tcp dst 80,443 (HTTP/HTTPS)
  3. ALLOW udp dst 53 (DNS)
  4. DROP all from 10.0.0.0/8 (block private range)
  5. LOG + DROP all (default deny)

[ALLOW] TCP 192.168.1.100:54321 -> 8.8.8.8:443 (rule 2)
[ALLOW] UDP 192.168.1.100:12345 -> 8.8.8.8:53 (rule 3)
[DROP]  TCP 10.1.2.3:54321 -> 192.168.1.100:22 (rule 4)
[DROP]  ICMP 203.0.113.50 -> 192.168.1.100 (rule 5)

Stats: 1234 packets processed, 156 dropped, 1078 allowed

Implementation Hints: You can build a firewall in two ways:

  1. Netfilter NFQUEUE: Kernel sends packets to userspace for decision
  2. BPF/eBPF: Attach filtering programs directly in kernel (advanced)

For learning, NFQUEUE is more approachable.

Pseudo-code approach:

1. Load rules from config file
   - Parse: action direction proto src dst port
2. Set up iptables rule to queue packets:
   $ iptables -A INPUT -j NFQUEUE --queue-num 0
3. Open NFQUEUE handle (libnetfilter_queue)
4. For each queued packet:
   a. Parse IP header (src, dst, protocol)
   b. If TCP/UDP, parse port numbers
   c. Check against rules in order
   d. First matching rule wins: ACCEPT, DROP, or LOG+DROP
   e. Set verdict with nfq_set_verdict()
5. On shutdown: remove iptables rule

Rules file format example:

ALLOW tcp any any 22      # SSH
ALLOW tcp any any 80,443  # Web
BLOCK any 10.0.0.0/8 any  # Private networks
LOG   any any any         # Log everything else
DROP  any any any         # Default deny

Learning milestones:

  1. Packets arrive in userspace → You understand NFQUEUE
  2. Rules match correctly → You understand packet inspection
  3. Blocked traffic actually stops → You’re running a real firewall
  4. Connection tracking works → You understand stateful filtering

Project 14: Software Router with NAT

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C
  • Alternative Programming Languages: Go, Rust
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Routing / NAT / IP Forwarding
  • Software or Tool: Linux router / iptables NAT
  • Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A software router that forwards packets between two network interfaces, performs NAT (Network Address Translation), and maintains a routing table—turning a Linux box into a real router.

Why it teaches networking: This is where you truly understand how the internet works. Routers make forwarding decisions based on destination IP and routing tables. NAT is the magic that lets millions of devices share one public IP. After building this, you’ll understand your home router completely.

Core challenges you’ll face:

  • Enabling IP forwarding in the kernel → maps to kernel networking parameters
  • Reading/modifying the routing table → maps to ip route internals
  • Implementing NAT (SNAT/DNAT) → maps to address translation mechanics
  • Port mapping for NAT → maps to connection tracking
  • Handling routing decisions → maps to longest prefix match

Key Concepts:

  • IP Forwarding: “Linux Kernel Networking” Chapter 5 - Rami Rosen
  • NAT Concepts: “TCP/IP Illustrated, Volume 1” Chapter 7 - W. Richard Stevens
  • Routing Tables: “Understanding Linux Network Internals” Chapter 30 - Christian Benvenuti
  • iptables NAT: “Linux Firewalls” Chapter 7 - Steve Suehring

Resources for key challenges:

Difficulty: Expert Time estimate: 3-4 weeks Prerequisites: Projects 4 and 13, deep understanding of IP addressing

Real world outcome:

$ sudo ./myrouter --lan eth1 --wan eth0 --nat
Software Router starting...
  LAN interface: eth1 (192.168.2.1/24)
  WAN interface: eth0 (DHCP: 10.0.0.50)
  NAT enabled

Routing table:
  192.168.2.0/24 -> eth1 (directly connected)
  0.0.0.0/0 -> 10.0.0.1 via eth0 (default gateway)

NAT translations:
  192.168.2.10:54321 <-> 10.0.0.50:40001 -> 8.8.8.8:53
  192.168.2.11:54322 <-> 10.0.0.50:40002 -> 142.250.80.46:443

[FORWARD] 192.168.2.10 -> 8.8.8.8 (DNS query)
[NAT] 192.168.2.10:54321 translated to 10.0.0.50:40001
[FORWARD] 192.168.2.11 -> 142.250.80.46 (HTTPS)

Stats: 12,456 packets forwarded, 234 dropped (no route)

Implementation Hints: You can build a router at two levels:

  1. Kernel-level (easy): Enable ip_forward and use iptables for NAT
  2. Userspace (hard but educational): Use NFQUEUE to make forwarding decisions

For learning, start with kernel-level, then understand what it does:

Pseudo-code (kernel-level approach):

1. Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward

2. Set up NAT with iptables:
   iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

3. Forward traffic between interfaces:
   iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
   iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

4. Your code monitors and logs:
   - Read from /proc/net/nf_conntrack for NAT translations
   - Read from /proc/net/stat/ip_conntrack for stats
   - Manage DHCP for LAN clients (Project 8)

Userspace approach involves intercepting packets, modifying headers, recalculating checksums, and re-injecting—much more complex but deeply educational.

Learning milestones:

  1. Packets forward between interfaces → You understand IP forwarding
  2. NAT works and you see translations → You understand address translation
  3. LAN clients can reach the internet → You’ve built a working router
  4. You understand the conntrack table → You understand stateful NAT

Project 15: Wake-on-LAN Tool

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: C, Go, Bash
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Magic Packets / Broadcast
  • Software or Tool: wakeonlan/etherwake clone
  • Main Book: “TCP/IP Guide” by Charles M. Kozierok

What you’ll build: A tool that wakes up sleeping computers on your network by sending “magic packets”—a useful utility that demonstrates broadcast communication and low-level Ethernet features.

Why it teaches networking: Wake-on-LAN uses raw Ethernet broadcasts without any IP addressing (though often sent via UDP broadcast). It’s a simple but practical example of Layer 2 communication and how network cards can respond to specific byte patterns even when the computer is “off.”

Core challenges you’ll face:

  • Understanding magic packet format → maps to simple protocol design
  • Sending UDP broadcasts → maps to broadcast addressing
  • Or sending raw Ethernet frames → maps to Layer 2 access
  • MAC address parsing → maps to hardware addressing

Key Concepts:

  • Wake-on-LAN Protocol: AMD Magic Packet Technology Whitepaper
  • Broadcast Addressing: “TCP/IP Guide” Chapter 20 - Charles M. Kozierok
  • Raw Ethernet: “Linux Socket Programming” Chapter 15 - Warren W. Gay

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic socket programming, understanding of MAC addresses

Real world outcome:

$ ./mywol aa:bb:cc:11:22:33
Sending magic packet to aa:bb:cc:11:22:33
Broadcast to 255.255.255.255:9
Magic packet sent!

# On another machine:
$ ./mywol --interface eth0 --mac aa:bb:cc:11:22:33 --count 3
Sending 3 magic packets...
Packet 1 sent
Packet 2 sent
Packet 3 sent
Done. Check if the target machine is waking up.

# The target computer wakes from sleep!

Implementation Hints: The magic packet is simple:

  1. 6 bytes of 0xFF (synchronization stream)
  2. Target MAC address repeated 16 times (96 bytes)
  3. Total: 102 bytes

Pseudo-code approach:

1. Parse MAC address from command line (e.g., "aa:bb:cc:11:22:33")
2. Convert to bytes: [0xaa, 0xbb, 0xcc, 0x11, 0x22, 0x33]
3. Build magic packet:
   - 6 bytes of 0xFF
   - MAC address × 16
4. Create UDP socket
5. Enable broadcast: setsockopt(SO_BROADCAST)
6. Send packet to 255.255.255.255:9 (or :7)

That’s it! Wake-on-LAN must be enabled in the target computer’s BIOS and network driver.

Learning milestones:

  1. You craft the magic packet → You understand simple protocol construction
  2. Packet sends without errors → You understand broadcast UDP
  3. Target machine wakes up → You understand WoL works at the NIC level
  4. You send via raw Ethernet → You understand Layer 2 (optional advanced step)

Project 16: mDNS/Bonjour Service Discovery

  • File: LEARN_HOME_OFFICE_NETWORKING.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 3: Advanced
  • Knowledge Area: Multicast DNS / Zero-Configuration
  • Software or Tool: Avahi/Bonjour clone
  • Main Book: “Zero Configuration Networking: The Definitive Guide” by Cheshire & Steinberg

What you’ll build: A tool that discovers services on your local network (printers, file shares, Chromecasts) using mDNS/DNS-SD, and optionally advertises your own services—the technology behind “zero-config” networking.

Why it teaches networking: mDNS uses multicast instead of unicast, operates without any central server, and demonstrates how distributed systems can work on a LAN. You’ll understand why your printer “just appears” and how AirPlay devices find each other.

Core challenges you’ll face:

  • Multicast group membership → maps to IGMP and multicast addressing
  • mDNS packet format → maps to DNS over multicast
  • Service discovery (DNS-SD) → maps to PTR, SRV, TXT records
  • Conflict resolution → maps to distributed coordination
  • Continuous querying → maps to cache maintenance

Key Concepts:

  • mDNS Specification: RFC 6762
  • DNS-SD Specification: RFC 6763
  • Multicast Networking: “TCP/IP Guide” Chapter 31 - Charles M. Kozierok
  • Zero-Configuration: “Zero Configuration Networking” Chapters 1-5 - Cheshire & Steinberg

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Project 5 (DNS Resolver), understanding of multicast

Real world outcome:

$ ./mymdns discover
Discovering services on local network...

_http._tcp.local:
  - My-MacBook._http._tcp.local (192.168.1.100:80)
    TXT: path=/

_printer._tcp.local:
  - HP-LaserJet._printer._tcp.local (192.168.1.50:631)
    TXT: pdl=application/postscript

_googlecast._tcp.local:
  - Living-Room-TV._googlecast._tcp.local (192.168.1.75:8009)
    TXT: fn=Living Room TV, md=Chromecast

_ssh._tcp.local:
  - raspberrypi._ssh._tcp.local (192.168.1.30:22)

$ ./mymdns announce --name myservice --type _http._tcp --port 8080
Announcing myservice._http._tcp.local on port 8080...
Service registered. Press Ctrl+C to unregister.

Implementation Hints: mDNS uses:

  • Multicast address: 224.0.0.251 (IPv4) or ff02::fb (IPv6)
  • Port: 5353
  • DNS packet format (same as regular DNS)

Pseudo-code for discovery:

1. Create UDP socket
2. Join multicast group 224.0.0.251 (setsockopt IP_ADD_MEMBERSHIP)
3. Bind to port 5353
4. Send mDNS query:
   - Question: _services._dns-sd._udp.local PTR?
   - Or specific: _http._tcp.local PTR?
5. Listen for responses:
   - Parse PTR records (service names)
   - Follow up with SRV queries (host and port)
   - Follow up with A queries (IP address)
   - Parse TXT records (metadata)
6. Build service list

For advertising, you respond to queries with your service info instead of asking.

Learning milestones:

  1. You receive mDNS traffic → You understand multicast
  2. You parse service announcements → You understand DNS-SD
  3. You discover real devices → You see zero-config in action
  4. You advertise a service → You participate in the mDNS network

Project 17: HTTP Proxy Server

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, Rust, C
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: HTTP Proxy / HTTPS Tunneling
  • Software or Tool: Squid/mitmproxy clone (basic)
  • Main Book: “HTTP: The Definitive Guide” by David Gourley & Brian Totty

What you’ll build: An HTTP/HTTPS proxy server that intercepts browser traffic, can log/modify requests, and teaches you how corporate proxies and debugging tools work.

Why it teaches networking: Proxies sit between client and server, seeing all traffic. Building one teaches you about HTTP request/response flow, the CONNECT method for HTTPS tunneling, and how content filtering, caching, and corporate surveillance work. You’ll understand why certain websites might be blocked at work.

Core challenges you’ll face:

  • Parsing HTTP requests → maps to text protocol handling
  • Forwarding requests to origin servers → maps to acting as client and server
  • HTTPS CONNECT tunneling → maps to TCP relay
  • Connection pooling → maps to efficiency and keep-alive
  • Request/response modification → maps to man-in-the-middle concepts

Key Concepts:

  • HTTP Proxy Specification: RFC 7230 Section 5.7
  • CONNECT Method: RFC 7231 Section 4.3.6
  • Caching Proxies: “HTTP: The Definitive Guide” Chapters 7-8 - Gourley & Totty
  • TLS Interception: “Practical Packet Analysis” Chapter 9 - Sanders

Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Project 11 (HTTP Server), understanding of HTTPS

Real world outcome:

$ ./myproxy --port 8888 --log
HTTP Proxy listening on port 8888
Configure your browser to use localhost:8888

[LOG] GET http://example.com/ -> 200 OK (1.2KB, 45ms)
[LOG] GET http://example.com/style.css -> 200 OK (3.4KB, 23ms)
[LOG] CONNECT www.google.com:443 -> 200 Connection Established
[LOG] CONNECT api.github.com:443 -> 200 Connection Established

Stats:
  Requests: 156
  CONNECT tunnels: 89
  Cached responses: 23
  Blocked: 0

# With blocking enabled:
$ ./myproxy --port 8888 --block "ads.*.com,tracker.*"
[BLOCKED] GET http://ads.example.com/banner.jpg -> 403 Forbidden

Implementation Hints: An HTTP proxy handles two types of requests:

  1. Plain HTTP: Full URL in request line 
    GET http://example.com/page HTTP/1.1

    Forward request to origin server, relay response back.

  2. HTTPS (CONNECT): Establish TCP tunnel 
    CONNECT www.google.com:443 HTTP/1.1

    Respond with “200 Connection Established”, then blindly relay bytes.

Pseudo-code approach:

1. Listen on proxy port
2. For each client connection:
   a. Read HTTP request
   b. If method is CONNECT:
      - Connect to target host:port
      - Send "HTTP/1.1 200 Connection Established\r\n\r\n"
      - Relay bytes bidirectionally until either side closes
   c. Else (GET, POST, etc.):
      - Parse full URL from request line
      - Connect to origin server
      - Forward request (possibly modified)
      - Receive response
      - Forward response to client
      - Log the transaction

For HTTPS interception (seeing decrypted content), you’d need to do TLS termination with a custom CA certificate—much more advanced.

Learning milestones:

  1. Plain HTTP proxying works → You understand request forwarding
  2. HTTPS CONNECT works → You understand TCP tunneling
  3. You log all traffic → You understand proxy visibility
  4. You block specific domains → You understand content filtering

Project 18: Network Topology Mapper

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Network Discovery / Visualization
  • Software or Tool: Network mapping tool
  • Main Book: “Network Warrior” by Gary A. Donahue

What you’ll build: A tool that discovers and maps your entire network topology—routers, switches, hosts—and generates a visual diagram showing how everything connects.

Why it teaches networking: This project synthesizes everything: ARP for local discovery, ICMP for reachability, traceroute for path discovery, SNMP for device details. You’ll understand your network’s structure and how professionals document networks.

Core challenges you’ll face:

  • Combining multiple discovery methods → maps to multi-protocol integration
  • SNMP querying for device info → maps to network management protocols
  • Graph construction → maps to data structures
  • Visualization → maps to graph rendering
  • Identifying device types → maps to fingerprinting

Key Concepts:

  • SNMP Basics: “TCP/IP Guide” Chapter 74 - Charles M. Kozierok
  • Network Discovery: “Nmap Network Scanning” Chapter 2 - Fyodor
  • Graph Visualization: “Graph Algorithms the Fun Way” Chapter 13 - Jeremy Kubica
  • Network Documentation: “Network Warrior” Chapter 2 - Gary A. Donahue

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1, 2, 3 (ARP scanner, ping, traceroute)

Real world outcome:

$ ./mynetmap --output network.html
Discovering network topology...

Phase 1: ARP scan for local hosts...
  Found 12 hosts on 192.168.1.0/24

Phase 2: ICMP ping sweep...
  11 hosts responding

Phase 3: Traceroute to gateway and beyond...
  Mapping path to internet

Phase 4: SNMP queries (where available)...
  Router: Netgear R7000 (192.168.1.1)
  Switch: Unmanaged (detected by MAC)

Topology:
  Internet
     |
  [Router: 192.168.1.1]
     |
  [Switch]
     |--- [192.168.1.10] MacBook Pro
     |--- [192.168.1.11] iPhone
     |--- [192.168.1.12] Raspberry Pi
     |--- [192.168.1.13] Smart TV
     |--- [192.168.1.14] Printer

Saved interactive map to network.html

Implementation Hints: Combine techniques from earlier projects:

Pseudo-code approach:

1. Determine local network (from interface config)
2. ARP scan to find all live hosts
3. For each host:
   a. Ping to verify reachability
   b. Try SNMP queries (sysDescr, sysName) if port 161 open
   c. Check common ports to identify device type
4. Traceroute to default gateway and beyond
5. Build graph:
   - Nodes: each discovered device
   - Edges: connectivity (same subnet = same switch)
6. Identify router (gateway), potential switches
7. Generate visualization:
   - Use graphviz, D3.js, or similar
   - Output as HTML/SVG/PNG

Device fingerprinting hints:

  • MAC OUI: Identifies manufacturer
  • Open ports: 22=SSH (probably server), 80=web, 631=printer
  • SNMP sysDescr: Full device description

Learning milestones:

  1. You discover all local hosts → You’ve integrated ARP scanning
  2. You identify device types → You understand fingerprinting
  3. You map paths through routers → You understand traceroute integration
  4. You generate a visual diagram → You can document networks professionally

Project 19: Simple VPN Server

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C
  • Alternative Programming Languages: Go, Rust
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Tunneling / TUN-TAP / Encryption
  • Software or Tool: WireGuard/OpenVPN clone (simplified)
  • Main Book: “Serious Cryptography” by Jean-Philippe Aumasson

What you’ll build: A VPN that creates an encrypted tunnel between two machines, allowing secure communication over untrusted networks—the fundamental technology behind corporate VPNs and privacy tools.

Why it teaches networking: VPNs combine everything: tunneling (encapsulating packets inside packets), encryption, TUN/TAP virtual interfaces, and routing. After building one, you’ll understand how your corporate VPN works, why VPNs sometimes slow things down, and the difference between various VPN protocols.

Core challenges you’ll face:

  • TUN/TAP device programming → maps to virtual network interfaces
  • Packet encapsulation → maps to tunneling concepts
  • Symmetric encryption → maps to AES, ChaCha20
  • Key exchange → maps to Diffie-Hellman, public key crypto
  • Routing for VPN → maps to split tunneling, default gateway

Key Concepts:

  • TUN/TAP Devices: “Linux Device Drivers” Chapter 17 - Corbet, Rubini, Kroah-Hartman
  • Tunneling Protocols: “TCP/IP Illustrated, Volume 1” Chapter 4 - W. Richard Stevens
  • Symmetric Encryption: “Serious Cryptography” Chapters 4-5 - Jean-Philippe Aumasson
  • Key Exchange: “Serious Cryptography” Chapter 12 - Jean-Philippe Aumasson

Difficulty: Expert Time estimate: 3-4 weeks Prerequisites: All previous projects, basic cryptography understanding

Real world outcome:

# On server:
$ sudo ./myvpn server --listen 0.0.0.0:51820 --network 10.8.0.0/24
VPN Server starting...
  Tunnel IP: 10.8.0.1
  Listening on UDP port 51820
  Public key: xyzABC123...

Waiting for connections...

# On client:
$ sudo ./myvpn client --server vpn.example.com:51820 --key xyzABC123...
Connecting to VPN server...
  Tunnel established!
  Your VPN IP: 10.8.0.2
  Routing all traffic through VPN

$ curl ifconfig.me
203.0.113.50  # Server's public IP, not yours!

# Server log:
[CLIENT] 10.8.0.2 connected from 198.51.100.1
[TUNNEL] 10.8.0.2 -> 8.8.8.8 (DNS query)
[TUNNEL] 10.8.0.2 -> 142.250.80.46 (HTTPS)

Stats: 1.2 MB sent, 15.4 MB received, 0 errors

Implementation Hints: A VPN works like this:

  1. Create a TUN device (virtual network interface)
  2. Configure routing so traffic goes through TUN
  3. Read packets from TUN, encrypt, send over UDP to peer
  4. Receive UDP, decrypt, write to TUN

Pseudo-code approach:

Server:
1. Create TUN device: open("/dev/net/tun")
2. Configure TUN with IP 10.8.0.1
3. Create UDP socket, bind to public port
4. Generate keypair for encryption

5. Loop:
   a. Select on TUN and UDP socket
   b. If TUN readable:
      - Read packet (destined for VPN client)
      - Encrypt with session key
      - Send over UDP to client
   c. If UDP readable:
      - Receive encrypted packet from client
      - Decrypt
      - Write to TUN (kernel will route it)

Client:
1. Create TUN device
2. Connect to server UDP
3. Key exchange (Diffie-Hellman or similar)
4. Add route: default -> TUN device
5. Loop: same as server, opposite direction

For encryption, use a library (libsodium, OpenSSL). Key exchange is the hardest part—start with a pre-shared key for simplicity.

Learning milestones:

  1. TUN device works → You understand virtual interfaces
  2. Packets flow through tunnel → You understand encapsulation
  3. Traffic is encrypted → You understand VPN security
  4. Full internet goes through VPN → You understand routing changes

Project 20: Complete Home Network Stack (Capstone)

  • File: LEARN_HOME_OFFICE_NETWORKING.md
  • Main Programming Language: C, Python
  • Alternative Programming Languages: Go, Rust
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 5: Master
  • Knowledge Area: Full Network Stack
  • Software or Tool: Complete home router/firewall suite
  • Main Book: All books referenced above

What you’ll build: A complete replacement for your home router’s software—DHCP server, DNS server with ad-blocking, NAT, firewall, bandwidth monitoring, and web dashboard—running on a Raspberry Pi or old PC.

Why it teaches networking: This capstone project integrates everything you’ve learned. You’ll run production network infrastructure for your home, troubleshoot real issues, and understand why commercial routers work the way they do.

Core challenges you’ll face:

  • Integrating all previous projects → maps to systems integration
  • Process management → maps to service supervision
  • Web dashboard → maps to monitoring and management
  • Reliability and recovery → maps to production operations
  • Performance tuning → maps to optimization

Key Concepts:

  • System Integration: Experience from all previous projects
  • Service Management: “DevOps for the Desperate” - Bradley Smith
  • Monitoring Dashboards: “The Practice of System and Network Administration” - Limoncelli, Hogan, Chalup
  • Network Reliability: “Network Warrior” - Gary A. Donahue

Difficulty: Master Time estimate: 1-2 months Prerequisites: All previous projects

Real world outcome:

$ sudo ./mynetstack start
Starting Home Network Stack...

[OK] DHCP Server started (pool: 192.168.1.100-200)
[OK] DNS Server started (upstream: 8.8.8.8, 1.1.1.1)
[OK] DNS Sinkhole loaded (150,000 blocked domains)
[OK] NAT enabled (eth0 -> eth1)
[OK] Firewall active (5 rules)
[OK] Bandwidth monitor started
[OK] Web dashboard at http://192.168.1.1:8080

All services running. Your network is online!

# Web dashboard shows:
- Connected devices (12)
- Bandwidth usage (real-time graph)
- DNS queries (blocked: 37%, total: 5,234)
- DHCP leases (active: 8)
- Firewall stats (blocked: 156 packets)
- System health (CPU, memory, uptime)

Implementation Hints: This is about integration, not new concepts:

Architecture:

mynetstack/
├── dhcp/         # From Project 8
├── dns/          # From Project 7 + Project 10 (sinkhole)
├── firewall/     # From Project 13
├── router/       # From Project 14
├── monitor/      # From Project 12
├── web/          # New: Flask/FastAPI dashboard
├── config/       # Unified configuration
└── main.py       # Service supervisor

Pseudo-code for main supervisor:

1. Load configuration (YAML/JSON)
2. Start each service as subprocess:
   - DHCP server on eth1
   - DNS server on 53
   - Enable NAT with iptables
   - Start firewall rules
   - Start bandwidth monitor
3. Start web server for dashboard
4. Monitor all services:
   - Restart if crashed
   - Log errors
   - Expose health metrics
5. Handle signals (SIGTERM -> graceful shutdown)

The web dashboard aggregates data from all services and presents a unified view.

Learning milestones:

  1. All services start together → You understand service orchestration
  2. Your home runs on your stack → You’re running production infrastructure
  3. Dashboard shows all metrics → You understand observability
  4. It survives a power outage → You understand reliability
  5. You can troubleshoot any issue → You’ve mastered networking

Project Comparison Table

# Project Difficulty Time Depth of Understanding Fun Factor Best For
1 Network Device Scanner Beginner Weekend ⭐⭐ ⭐⭐⭐ First networking project
2 Build Your Own ping Intermediate 1 week ⭐⭐⭐ ⭐⭐⭐ Learning ICMP
3 Build Your Own traceroute Intermediate 1 week ⭐⭐⭐⭐ ⭐⭐⭐⭐ Understanding routing
4 Packet Sniffer Advanced 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ Deep protocol understanding
5 DNS Resolver Intermediate 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐ DNS fundamentals
6 DHCP Client Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐ IP configuration
7 DNS Server Advanced 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ Running DNS infrastructure
8 DHCP Server Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐ Running DHCP infrastructure
9 Port Scanner Intermediate 1 week ⭐⭐⭐ ⭐⭐⭐⭐ Security basics
10 DNS Sinkhole Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Ad-blocking, practical use
11 HTTP Server Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐ Web fundamentals
12 Bandwidth Monitor Intermediate 1 week ⭐⭐⭐ ⭐⭐⭐⭐ Practical monitoring
13 Packet Filter Firewall Advanced 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ Security, netfilter
14 Software Router + NAT Expert 3-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Core router functionality
15 Wake-on-LAN Tool Beginner Weekend ⭐⭐ ⭐⭐ Quick win, practical
16 mDNS/Bonjour Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐ Zero-config networking
17 HTTP Proxy Advanced 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐ Web traffic interception
18 Network Topology Mapper Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Visualization, integration
19 Simple VPN Expert 3-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Tunneling, encryption
20 Complete Home Stack Master 1-2 months ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Full integration, capstone

If you’re a complete beginner:

Start with Project 1 (Network Scanner) → Project 15 (Wake-on-LAN) → Project 2 (ping) → Project 9 (Port Scanner). These give you quick wins and foundational understanding.

If you know basic programming but not networking:

Follow the order: 1 → 2 → 3 → 5 → 4 → 7 → 10. This takes you from discovery to DNS to packet analysis.

If you want to understand your home router:

Focus on: 6 → 8 → 14 → 13 → 10. You’ll understand DHCP, routing, NAT, and DNS filtering.

If you’re into security:

Prioritize: 4 → 9 → 13 → 17 → 19. Packet sniffing, port scanning, firewalls, proxies, and VPNs.

If you want maximum “cool factor”:

Go for: 4 → 14 → 19 → 20. Packet sniffer, software router, VPN, and the complete stack.

My Top Recommendation

Start with Project 1 (Network Scanner), then immediately do Project 4 (Packet Sniffer).

Why?

  • Project 1 is quick (weekend) and gives you immediate gratification—you’ll see all devices on your network
  • Project 4 (while harder) is the most educational single project—after building a packet sniffer, you’ll never look at networks the same way

Then progress to Project 5 (DNS Resolver) and Project 14 (Software Router) to understand the two most fundamental networking concepts: name resolution and packet forwarding.

Summary: All Projects

# Project Name Main Language
1 Network Device Scanner (ARP Discovery) Python
2 Build Your Own ping Utility C
3 Build Your Own traceroute Utility C
4 Network Packet Sniffer C
5 DNS Resolver (Client-Side) Python
6 DHCP Client C
7 Simple DNS Server Python
8 DHCP Server C
9 Port Scanner Python
10 DNS Sinkhole (Pi-hole Clone) Python
11 Simple HTTP Server C
12 Bandwidth Monitor Python
13 Simple Packet Filter Firewall C
14 Software Router with NAT C
15 Wake-on-LAN Tool Python
16 mDNS/Bonjour Service Discovery Python
17 HTTP Proxy Server Python
18 Network Topology Mapper Python
19 Simple VPN Server C
20 Complete Home Network Stack (Capstone) C, Python

Essential Resources

Books (from your library)

  • “TCP/IP Illustrated, Volume 1” by W. Richard Stevens - The networking bible
  • “TCP/IP Guide” by Charles M. Kozierok - Exhaustive reference
  • “Computer Networks” by Andrew S. Tanenbaum - Academic foundation
  • “The Linux Programming Interface” by Michael Kerrisk - Linux systems programming
  • “Black Hat Python” by Justin Seitz - Security-focused networking
  • “Unix Network Programming, Vol 1” by W. Richard Stevens - Socket programming definitive guide

Online Resources

RFCs (the real specifications)

  • RFC 792 - ICMP
  • RFC 1035 - DNS
  • RFC 2131 - DHCP
  • RFC 7230-7235 - HTTP/1.1
  • RFC 6762 - mDNS
  • RFC 6763 - DNS-SD

Happy networking! Remember: the best way to understand a protocol is to implement it.