Project 12: Bandwidth Monitor

A real-time bandwidth monitor that aggregates traffic by device and protocol.

Quick Reference

Attribute	Value
Difficulty	Level 2: Intermediate
Time Estimate	Week
Main Programming Language	Python
Alternative Programming Languages	C, Go, Rust
Coolness Level	Level 3: Genuinely Clever
Business Potential	3. The “Service & Support” Model
Prerequisites	See concepts below
Key Topics	Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching), Operations, Diagnostics, and Security

1. Learning Objectives

Build and validate: A real-time bandwidth monitor that aggregates traffic by device and protocol..
Explain protocol behavior and verify it with a capture or trace.
Handle edge cases and produce reproducible results.

2. All Theory Needed (Per-Concept Breakdown)

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.

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.

3. Project Specification

3.1 What You Will Build

A real-time bandwidth monitor that aggregates traffic by device and protocol.

Included:

CLI tool with clear output
Validation steps and logging
Documentation of assumptions

Excluded:

Production-grade performance tuning
Full security hardening

3.2 Functional Requirements

Core function: Implement the primary behavior described in the project goal.
Observable output: Produce deterministic output comparable to the Real World Outcome.
Error handling: Handle timeouts, invalid inputs, and unreachable hosts gracefully.

3.3 Non-Functional Requirements

Performance: Complete typical tasks within a few seconds on a LAN.
Reliability: Fail safely and clearly on errors.
Usability: Provide concise CLI flags and helpful messages.

3.4 Example Usage / Output

$ 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

3.5 Data Formats / Schemas / Protocols

Protocols: Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching), Operations, Diagnostics, and Security.

3.6 Edge Cases

Target unreachable or timing out
Malformed or unexpected responses
Multiple interfaces or subnets

3.7 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

3.7.1 How to Run (Copy/Paste)

Build: make (or create a virtual environment as needed)
Run: ./P12-bandwidth-monitor
Config: update any constants in a config file or flags
Working directory: project root

3.7.2 Golden Path Demo (Deterministic)

Run against a known local target and compare with the expected output.

3.7.3 If CLI: provide an exact terminal transcript

$ 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

4. Solution Architecture

4.1 High-Level Design

CLI Input -> Core Engine -> Output/Logs

4.2 Key Components

Component	Responsibility	Key Decisions
CLI Parser	Parse flags and inputs	Keep interface minimal
Core Engine	Protocol logic and state	Keep deterministic timing
Output/Logs	Present results and errors	Use consistent formatting

4.4 Data Structures (No Full Code)

Request:
  - target
  - protocol fields
Response:
  - status
  - timing
State:
  - retries
  - cache entries

5. Implementation Guide

5.1 Development Environment Setup

Ensure required tools (tcpdump, dig, ip) are installed.
Use elevated privileges where raw sockets are required.

5.2 Project Structure

project/
  README.md
  docs/
  src/
  tests/
  data/

5.3 The Core Question You’re Answering

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

5.4 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

5.5 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?

5.6 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?

5.7 The Interview Questions They’ll 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?”

5.8 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.

5.9 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

5.10 Implementation Phases

Establish core protocol I/O and a minimal success path.
Add parsing, validation, and timeouts.
Add logging, metrics, and polish for output.

5.11 Key Implementation Decisions

Which interface and capture point provides visibility?
What timeout and retry strategy balances speed and accuracy?
How will results be validated against reference tools?

6. Testing Strategy

6.1 Test Categories

Unit: parsing and validation logic
Integration: protocol exchange with a real device
System: full run with reference tools

6.2 Critical Test Cases

Successful request/response path
Timeout and retry behavior
Invalid or unexpected input handling

6.3 Test Data

Local gateway IP and a known reachable host
A non-routable IP to trigger timeouts

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

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.

7.2 Debugging Strategies

Capture traffic with tcpdump or Wireshark.
Compare against a known-good tool.
Log timestamps and retry logic.

7.3 Performance Traps

Excessive retries causing long runtimes.
Inefficient parsing under high packet rates.

8. Extensions & Challenges

8.1 Beginner Extensions

Add basic configuration flags for interface and timeout.
Improve output formatting and sorting.

8.2 Intermediate Extensions

Add caching or state persistence.
Add CSV or JSON output export.

8.3 Advanced Extensions

Add concurrency with careful rate limiting.
Add visualization or integration with a dashboard.

9. Real-World Connections

9.1 Industry Applications

Network diagnostics and troubleshooting
Security monitoring and policy enforcement

tcpdump / Wireshark
nmap / dnsmasq / unbound (as applicable)

9.3 Interview Relevance

Explaining protocol behavior
Diagnosing failures by layer

10. Resources

10.1 Essential Reading

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

10.2 Video Resources

Wireshark or tcpdump walkthroughs (search for recent tutorials)
Vendor or RFC explainers for the relevant protocol

10.3 Tools & Documentation

RFCs for the protocols used in this project
man tcpdump, man ip, man ss