19  Networking: Labs and Quiz

Key Concepts

• Integrated Lab Assessment: An exercise combining hands-on lab work with a written quiz to verify both practical skills and theoretical understanding
• Lab-Quiz Connection: The practice of deriving quiz questions directly from lab observations, ensuring the quiz tests genuine understanding rather than memorised facts
• Measurement Accuracy: The degree to which a lab measurement reflects the true value of the quantity being measured; affected by instrument error, environmental noise, and sampling bias
• Lab Notebook: A structured record of hypotheses, procedures, raw data, and analysis; the primary evidence of scientific rigour in a lab exercise
• Pre-Lab Quiz: A short assessment taken before a lab to verify that the student understands the theory needed to conduct the exercise safely and productively
• Post-Lab Analysis: The structured interpretation of lab results, connecting measured values to theoretical predictions and explaining discrepancies
• Peer Review: Examining another student’s lab report to identify errors, missing steps, and unjustified conclusions — a key skill for professional engineering practice

19.1 In 60 Seconds

This hands-on lab chapter walks you through configuring ESP32 and Arduino devices for Wi-Fi connectivity: connecting to networks, retrieving IP/MAC addresses and signal strength, scanning for nearby access points, implementing reconnection logic, and configuring WPA2/WPA3 security. These are the essential practical skills for getting any IoT device online.

19.2 Learning Objectives

By the end of this chapter, you will be able to:

• Configure Wi-Fi Connectivity: Set up ESP32 and Arduino devices for wireless network connections
• Retrieve Network Information: Programmatically obtain IP addresses, MAC addresses, and signal strength
• Implement Network Scanning: Create tools to discover nearby networks and analyze wireless environments
• Debug Connection Issues: Troubleshoot common Wi-Fi configuration problems using serial output
• Apply Security Settings: Configure WPA2/WPA3 credentials for secure IoT device connectivity
• Monitor Network Status: Implement connection event handlers and reconnection logic

19.3 Prerequisites

Before starting these labs, you will get the most value if you are comfortable with:

• Networking Basics – IP addressing, subnets, and how packets move between devices
• Layered Models: Fundamentals – how link, network, and transport layers work together
• Wi-Fi Fundamentals and Standards – SSIDs, basic security (WPA2/WPA3), and coverage limits
• Basic command-line skills (running ping, ipconfig/ifconfig, traceroute) on your operating system

If any of these feel unfamiliar, skim the referenced chapters first and then return here for hands-on practice.

Related Chapters

Deep Dives:

• Network Mechanisms - Packet switching and bandwidth concepts
• Routing Fundamentals - How routers make forwarding decisions
• Transport Protocols - TCP vs UDP for IoT

Comparisons:

• Layered Network Models Review - OSI vs TCP/IP quiz
• IoT Protocols Review - Application-layer protocols

Hands-On:

• Wi-Fi IoT Implementations - ESP32 Wi-Fi projects
• Simulations Hub - Network simulation tools

Learning:

• Quizzes Hub - Test networking fundamentals
• Networking Review - Video tutorials

19.4 Getting Started (For Beginners)

For Beginners: How to Use These Networking Labs

These labs assume you have seen the core networking theory and are now ready to practice on real or simulated networks.

• If you have hardware (ESP32/Arduino and home Wi-Fi), focus on the C++ examples and follow the checklists in each lab.
• If you do not have hardware or cannot install tools, you can still learn a lot by:
  • reading the code and comments,
  • comparing the provided example outputs with what you see on your own laptop or VM,
  • answering the Knowledge Check questions using the explanations as a guide.

Key terms used throughout this chapter:

Term	Simple explanation
SSID	The name of a Wi-Fi network
Gateway	Router that forwards traffic to other networks
DNS server	Translates names like example.com to IP addresses
RSSI	Received Signal Strength Indicator (Wi-Fi signal)

If you ever feel lost, go back to Networking Basics and Wi-Fi Fundamentals to refresh the concepts, then return here and treat the Python tools as black-box helpers whose outputs you interpret rather than code you must fully understand line-by-line.

19.5 Hands-On: Network Configuration

Time: ~15 min | Level: Intermediate | Ref: P07.C16.U01

Lab network topology showing ESP32 connecting to home network

Figure 19.1: Lab Network Topology: ESP32 IoT device connecting to home network, showing DHCP IP assignment, DNS resolution through gateway router, and internet connectivity. The workflow demonstrates the complete network stack from Wi-Fi association through application-layer HTTP requests, with typical home network addressing (192.168.1.0/24 subnet).

Optional Walkthrough: ESP32 Boot-to-Network Timeline

Use this simple timing model when diagnosing startup delays:

1. Layer 2 scan and association: the ESP32 discovers the SSID, authenticates, and associates with the access point.
2. Layer 3 configuration: DHCP assigns an IP address, subnet mask, gateway, and DNS server.
3. Application setup: DNS resolution, TCP or TLS handshake, and the first MQTT or HTTP request complete.

Troubleshooting shortcut: if association succeeds but the IP stays 0.0.0.0 or 169.254.x.x, focus on DHCP and gateway policy rather than Wi-Fi signal strength.

19.5.1 Example 1: ESP32 Wi-Fi Connection

Optional Implementation Checklist: ESP32 Wi-Fi Trace

Use this checklist when you implement the hardware version. The point of the lab is to interpret the network state, not to memorize a long sketch.

Step	What the ESP32 should do	Evidence to record
1	Start the serial monitor at 115200 baud	Boot message appears.
2	Join the configured 2.4 GHz SSID	Status changes to connected.
3	Print the assigned IP address	A normal LAN address such as 192.168.x.x appears.
4	Print gateway, subnet mask, and DNS	Gateway and DNS are not 0.0.0.0.
5	Print MAC address and RSSI	MAC is stable; RSSI is better than about -75 dBm for reliable use.

Starter code is intentionally left to your ESP32 course template or Arduino examples so you can focus here on reading the network evidence.

Try It: ESP32 Wi-Fi Connection Trace

Use the browser activity below to practise reading the same network outputs before using real hardware.

viewof wifiTraceScenario = Inputs.select(
  ["Healthy connection", "Wrong password", "5 GHz only router", "Weak signal", "DHCP failure"],
  {value: "Healthy connection", label: "Choose a connection scenario"}
)

{
  const scenarios = {
    "Healthy connection": {
      ip: "192.168.1.42",
      gateway: "192.168.1.1",
      dns: "192.168.1.1",
      rssi: -57,
      status: "Connected",
      fix: "No fix required. Record the assigned IP, gateway, DNS, and RSSI as your baseline."
    },
    "Wrong password": {
      ip: "0.0.0.0",
      gateway: "0.0.0.0",
      dns: "0.0.0.0",
      rssi: -54,
      status: "Authentication failed",
      fix: "Check SSID spelling, password, and WPA mode. The signal is strong, so this is not a range problem."
    },
    "5 GHz only router": {
      ip: "0.0.0.0",
      gateway: "0.0.0.0",
      dns: "0.0.0.0",
      rssi: "not visible",
      status: "SSID not found",
      fix: "ESP32 Wi-Fi uses 2.4 GHz. Enable a 2.4 GHz SSID or use a dual-band access point."
    },
    "Weak signal": {
      ip: "192.168.1.77",
      gateway: "192.168.1.1",
      dns: "192.168.1.1",
      rssi: -83,
      status: "Connected but unreliable",
      fix: "Move the device, improve antenna placement, or add an access point. Expect retries and battery drain."
    },
    "DHCP failure": {
      ip: "169.254.12.9",
      gateway: "0.0.0.0",
      dns: "0.0.0.0",
      rssi: -60,
      status: "Link up, no usable network config",
      fix: "The device joined Wi-Fi but did not receive DHCP settings. Check DHCP pool, VLAN, gateway, and firewall rules."
    }
  };
  const s = scenarios[wifiTraceScenario];
  const rssiText = typeof s.rssi === "number" ? `${s.rssi} dBm` : s.rssi;

  return html`<div style="background:#f8faf9;border:1px solid #d9e6df;border-radius:10px;padding:16px;">
    <pre style="background:#17202A;color:#ECF0F1;border-radius:8px;padding:12px;white-space:pre-wrap;">WiFi.begin(ssid, password)
status: ${s.status}
localIP: ${s.ip}
gateway: ${s.gateway}
dns: ${s.dns}
RSSI: ${rssiText}</pre>
    <div style="background:white;border-left:4px solid ${s.status === 'Connected' ? '#16A085' : '#E67E22'};padding:12px;border-radius:6px;">
      <strong>Diagnosis:</strong> ${s.fix}
    </div>
  </div>`;
}

What to Try:

1. Switch between scenarios and read the trace like a serial monitor log
2. Decide whether the problem is credentials, frequency band, signal strength, or DHCP
3. Compare RSSI against the troubleshooting flowchart below
4. On real hardware, record a healthy baseline before diagnosing failures

Learning Activities:

• RSSI signal strength: Values near -50 dBm are strong; values below -80 dBm are unreliable
• IP address: 0.0.0.0 or 169.254.x.x means the device is not ready for normal network traffic
• Gateway and DNS: Missing values usually point to DHCP or network policy problems

Lab Extension: Build Your Own Network - With Hardware

Have real hardware? Follow these steps to connect your physical ESP32:

Hardware Needed:

• ESP32 development board
• USB cable
• Wi-Fi network (2.4 GHz – ESP32 does not support 5 GHz!)

Steps:

1. Flash a minimal ESP32 Wi-Fi sketch from your course template or Arduino examples with your SSID/password
2. Open Serial Monitor (115200 baud)
3. Observe IP address assignment via DHCP
4. Note the gateway and DNS servers
5. From your computer, ping the ESP32’s IP address
6. Modify code to ping google.com from ESP32

Challenge: Set a static IP instead of DHCP. Why might this be useful for IoT deployments?

Wi-Fi Troubleshooting Sequence

Use this order when an ESP32 will not get online:

1. Check SSID visibility first: if the network never appears, verify that the router is broadcasting 2.4 GHz because standard ESP32 Wi-Fi does not join 5 GHz-only networks.
2. Validate credentials next: strong RSSI with 0.0.0.0 often means the password or WPA mode is wrong rather than the signal being weak.
3. Inspect addressing after association: if the link comes up but the address is 169.254.x.x or the gateway stays 0.0.0.0, focus on DHCP, VLAN, or firewall policy.
4. Test name resolution and internet reachability last: if the ESP32 has an IP and gateway but cloud traffic still fails, check DNS, outbound filtering, and target host availability.

Fast rule of thumb: no SSID means radio or band issues; good RSSI with no IP means DHCP or credentials; valid IP with failed requests means DNS or upstream routing.

Quick Check: ESP32 Network Configuration

19.6 Python Implementations

Production-ready Python tools for network analysis and IoT networking.

19.6.1 IP Address Calculator and Subnet Analyzer

Optional Sample Reading: Subnet Analyzer

Input	Key result	What it means for an IoT lab
192.168.1.100/24	Network 192.168.1.0, broadcast 192.168.1.255, 254 usable hosts	Typical home or small lab subnet.
10.20.28.0/22	Mask 255.255.252.0, 1022 usable hosts	Better for a larger IoT lab where many devices need addresses.
Private address result	Yes for both examples	Suitable for local networks behind a gateway or NAT.

Try It: Interactive Subnet Calculator

Adjust the IP address octets and CIDR prefix length to see how the network address, broadcast address, and usable host count change in real time.

viewof octet1 = Inputs.range([0, 255], {value: 192, step: 1, label: "Octet 1"})
viewof octet2 = Inputs.range([0, 255], {value: 168, step: 1, label: "Octet 2"})
viewof octet3 = Inputs.range([0, 255], {value: 1, step: 1, label: "Octet 3"})
viewof octet4 = Inputs.range([0, 255], {value: 0, step: 1, label: "Octet 4"})
viewof cidr = Inputs.range([8, 30], {value: 24, step: 1, label: "CIDR Prefix"})

subnetCalc = {
  const ip = [octet1, octet2, octet3, octet4];
  const hostBits = 32 - cidr;
  const totalAddresses = Math.pow(2, hostBits);
  const usableHosts = totalAddresses > 2 ? totalAddresses - 2 : 0;

  // Build subnet mask
  const maskBits = "1".repeat(cidr) + "0".repeat(32 - cidr);
  const mask = [
    parseInt(maskBits.slice(0, 8), 2),
    parseInt(maskBits.slice(8, 16), 2),
    parseInt(maskBits.slice(16, 24), 2),
    parseInt(maskBits.slice(24, 32), 2)
  ];

  // Network address
  const network = ip.map((o, i) => o & mask[i]);

  // Broadcast address
  const invMask = mask.map(m => 255 - m);
  const broadcast = network.map((n, i) => n | invMask[i]);

  // First and last usable
  const firstUsable = [...network];
  firstUsable[3] += 1;
  const lastUsable = [...broadcast];
  lastUsable[3] -= 1;

  // Address class
  let addrClass = "Class A";
  if (ip[0] >= 128 && ip[0] <= 191) addrClass = "Class B";
  else if (ip[0] >= 192 && ip[0] <= 223) addrClass = "Class C";
  else if (ip[0] >= 224 && ip[0] <= 239) addrClass = "Class D (Multicast)";
  else if (ip[0] >= 240) addrClass = "Class E (Reserved)";

  // Private check
  const isPrivate = (ip[0] === 10) ||
    (ip[0] === 172 && ip[1] >= 16 && ip[1] <= 31) ||
    (ip[0] === 192 && ip[1] === 168);

  // IoT suitability
  let iotNote = "";
  if (usableHosts < 10) iotNote = "Very small subnet — suitable for a single sensor cluster.";
  else if (usableHosts < 50) iotNote = "Small subnet — good for a room-level IoT deployment.";
  else if (usableHosts < 254) iotNote = "Medium subnet — typical for a building floor.";
  else if (usableHosts < 1024) iotNote = "Large subnet — suitable for a multi-floor building.";
  else iotNote = "Very large subnet — suitable for campus or industrial IoT deployments.";

  // Utilization bar width
  const barPct = Math.min(100, (usableHosts / 1024) * 100);

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 14px; font-family: Arial, sans-serif; box-sizing: border-box; overflow: hidden;">
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(142px, 1fr)); gap: 12px;">
      <div style="background: white; border-left: 4px solid #2C3E50; padding: 12px; border-radius: 4px; min-width: 0; overflow-wrap: anywhere;">
        <div style="color: #7F8C8D; font-size: 0.85em;">IP Address</div>
        <div style="color: #2C3E50; font-size: 1.2em; font-weight: bold;">${ip.join(".")}/${cidr}</div>
      </div>
      <div style="background: white; border-left: 4px solid #16A085; padding: 12px; border-radius: 4px; min-width: 0; overflow-wrap: anywhere;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Subnet Mask</div>
        <div style="color: #16A085; font-size: 1.2em; font-weight: bold;">${mask.join(".")}</div>
      </div>
      <div style="background: white; border-left: 4px solid #3498DB; padding: 12px; border-radius: 4px; min-width: 0; overflow-wrap: anywhere;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Network Address</div>
        <div style="color: #3498DB; font-size: 1.2em; font-weight: bold;">${network.join(".")}</div>
      </div>
      <div style="background: white; border-left: 4px solid #E67E22; padding: 12px; border-radius: 4px; min-width: 0; overflow-wrap: anywhere;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Broadcast Address</div>
        <div style="color: #E67E22; font-size: 1.2em; font-weight: bold;">${broadcast.join(".")}</div>
      </div>
      <div style="background: white; border-left: 4px solid #9B59B6; padding: 12px; border-radius: 4px; min-width: 0; overflow-wrap: anywhere;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Usable Host Range</div>
        <div style="color: #9B59B6; font-size: 1.0em; font-weight: bold;">${firstUsable.join(".")} — ${lastUsable.join(".")}</div>
      </div>
      <div style="background: white; border-left: 4px solid #E74C3C; padding: 12px; border-radius: 4px; min-width: 0; overflow-wrap: anywhere;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Usable Hosts</div>
        <div style="color: #E74C3C; font-size: 1.2em; font-weight: bold;">${usableHosts.toLocaleString()}</div>
      </div>
    </div>
    <div style="margin-top: 16px; background: white; padding: 12px; border-radius: 4px;">
      <div style="display: flex; flex-wrap: wrap; gap: 0.4rem; justify-content: space-between; margin-bottom: 6px;">
        <span style="color: #7F8C8D; font-size: 0.85em;">${addrClass} | ${isPrivate ? "Private (RFC 1918)" : "Public"}</span>
        <span style="color: #7F8C8D; font-size: 0.85em;">${hostBits} host bits</span>
      </div>
      <div style="background: #ecf0f1; border-radius: 4px; height: 12px; overflow: hidden;">
        <div style="background: linear-gradient(90deg, #16A085, #3498DB); height: 100%; width: ${barPct}%; border-radius: 4px; transition: width 0.3s;"></div>
      </div>
      <div style="margin-top: 8px; color: #2C3E50; font-size: 0.9em;"><strong>IoT Planning:</strong> ${iotNote}</div>
    </div>
  </div>`;
}

19.6.2 Network Device Scanner

Optional Sample Reading: Device Scanner

Device	Likely role	Response time	Open ports	What to infer
192.168.1.1	Router or gateway	2.45 ms	80, 443	Local management interface is reachable.
192.168.1.100	ESP32 sensor	15.67 ms	80, 1883	Device exposes a web page and MQTT service.
192.168.1.150	Raspberry Pi	8.23 ms	22, 80, 1883	SSH plus web/MQTT suggests a gateway or test broker.

19.6.3 Protocol Performance Simulator

Optional Sample Reading: TCP vs UDP

Scenario: 100 packets, 100-byte payloads, 5% packet loss, 20 ms base latency.

Metric	TCP	UDP	Lab interpretation
Packets sent	105	100	TCP retries lost packets; UDP does not.
Delivered	100	95	TCP prioritizes completeness.
Total bytes	14.7 KB	12.8 KB	TCP reliability costs extra traffic.
Average latency	21 ms	20 ms	UDP stays slightly faster in this scenario.
Best fit	Firmware/configuration	Frequent sensor readings	Choose based on whether loss is acceptable.

Try It: TCP vs UDP Performance Explorer

Adjust network conditions to see how TCP and UDP behave differently. Change packet loss rate, base latency, and payload size to understand the trade-offs for IoT applications.

viewof pktLossRate = Inputs.range([0, 30], {value: 5, step: 1, label: "Packet Loss Rate (%)"})
viewof baseLatency = Inputs.range([1, 200], {value: 20, step: 1, label: "Base Latency (ms)"})
viewof payloadSize = Inputs.range([10, 1500], {value: 100, step: 10, label: "Payload Size (bytes)"})
viewof numPackets = Inputs.range([10, 500], {value: 100, step: 10, label: "Number of Packets"})

protocolComparison = {
  const loss = pktLossRate / 100;

  // TCP: retransmits lost packets, adds overhead (20-byte header), ACK latency
  const tcpHeaderSize = 20;
  const tcpRetransmissions = Math.ceil(numPackets * loss);
  const tcpTotalSent = numPackets + tcpRetransmissions;
  const tcpDelivered = numPackets; // TCP guarantees delivery
  const tcpAvgLatency = baseLatency + (loss * baseLatency * 1.5) + 5; // ACK overhead
  const tcpTotalBytes = tcpTotalSent * (payloadSize + tcpHeaderSize);
  const tcpThroughput = ((tcpDelivered * payloadSize * 8) / (tcpAvgLatency * numPackets)) * 1000;

  // UDP: no retransmissions, smaller header (8 bytes), no ACK
  const udpHeaderSize = 8;
  const udpTotalSent = numPackets;
  const udpLost = Math.round(numPackets * loss);
  const udpDelivered = numPackets - udpLost;
  const udpAvgLatency = baseLatency;
  const udpTotalBytes = udpTotalSent * (payloadSize + udpHeaderSize);
  const udpThroughput = ((udpDelivered * payloadSize * 8) / (udpAvgLatency * numPackets)) * 1000;

  // Recommendation
  let recommendation = "";
  let recColor = "#16A085";
  if (loss > 0.15) {
    recommendation = "High loss environment: TCP recommended for reliable delivery. UDP would lose too many sensor readings.";
    recColor = "#E74C3C";
  } else if (loss > 0.05) {
    recommendation = "Moderate loss: TCP for critical data (firmware, config). UDP acceptable for redundant sensor telemetry.";
    recColor = "#E67E22";
  } else if (baseLatency > 100) {
    recommendation = "High latency link (satellite/cellular): UDP preferred for real-time telemetry. TCP retransmissions would compound delays.";
    recColor = "#3498DB";
  } else {
    recommendation = "Good network conditions: Both protocols perform well. Choose based on reliability needs vs latency sensitivity.";
    recColor = "#16A085";
  }

  // Bar chart heights (max 140px)
  const maxThroughput = Math.max(tcpThroughput, udpThroughput, 1);
  const tcpBarH = Math.max(10, (tcpThroughput / maxThroughput) * 140);
  const udpBarH = Math.max(10, (udpThroughput / maxThroughput) * 140);

  const maxLatency = Math.max(tcpAvgLatency, udpAvgLatency, 1);
  const tcpLatBarH = Math.max(10, (tcpAvgLatency / maxLatency) * 140);
  const udpLatBarH = Math.max(10, (udpAvgLatency / maxLatency) * 140);

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 14px; font-family: Arial, sans-serif; box-sizing: border-box; overflow: hidden;">
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(170px, 1fr)); gap: 12px; margin-bottom: 12px;">
      <div style="background: white; border-radius: 8px; padding: 12px; text-align: center; min-width: 0;">
        <div style="font-weight: bold; color: #2C3E50; margin-bottom: 8px;">TCP (Reliable)</div>
        <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(82px, 1fr)); gap: 8px; font-size: 0.85em;">
          <div style="background: #eaf2f8; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Sent</div>
            <div style="color: #2C3E50; font-weight: bold;">${tcpTotalSent}</div>
          </div>
          <div style="background: #eaf2f8; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Delivered</div>
            <div style="color: #16A085; font-weight: bold;">${tcpDelivered} (100%)</div>
          </div>
          <div style="background: #eaf2f8; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Retransmissions</div>
            <div style="color: #E67E22; font-weight: bold;">${tcpRetransmissions}</div>
          </div>
          <div style="background: #eaf2f8; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Total Bytes</div>
            <div style="color: #2C3E50; font-weight: bold;">${(tcpTotalBytes / 1024).toFixed(1)} KB</div>
          </div>
        </div>
      </div>
      <div style="background: white; border-radius: 8px; padding: 12px; text-align: center; min-width: 0;">
        <div style="font-weight: bold; color: #2C3E50; margin-bottom: 8px;">UDP (Fast)</div>
        <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(82px, 1fr)); gap: 8px; font-size: 0.85em;">
          <div style="background: #fef9e7; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Sent</div>
            <div style="color: #2C3E50; font-weight: bold;">${udpTotalSent}</div>
          </div>
          <div style="background: #fef9e7; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Delivered</div>
            <div style="color: ${udpLost > 0 ? '#E74C3C' : '#16A085'}; font-weight: bold;">${udpDelivered} (${((udpDelivered / numPackets) * 100).toFixed(1)}%)</div>
          </div>
          <div style="background: #fef9e7; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Lost</div>
            <div style="color: #E74C3C; font-weight: bold;">${udpLost}</div>
          </div>
          <div style="background: #fef9e7; padding: 8px; border-radius: 4px;">
            <div style="color: #7F8C8D;">Total Bytes</div>
            <div style="color: #2C3E50; font-weight: bold;">${(udpTotalBytes / 1024).toFixed(1)} KB</div>
          </div>
        </div>
      </div>
    </div>
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(170px, 1fr)); gap: 12px; margin-bottom: 12px;">
      <div style="background: white; border-radius: 8px; padding: 12px; text-align: center; min-width: 0;">
        <div style="color: #7F8C8D; font-size: 0.85em; margin-bottom: 8px;">Throughput (Kbps)</div>
        <div style="display: flex; align-items: flex-end; justify-content: center; gap: 24px; height: 160px;">
          <div style="text-align: center;">
            <div style="color: #2C3E50; font-size: 0.8em; font-weight: bold; margin-bottom: 4px;">${tcpThroughput.toFixed(0)}</div>
            <div style="width: 50px; height: ${tcpBarH}px; background: linear-gradient(180deg, #3498DB, #2C3E50); border-radius: 4px 4px 0 0;"></div>
            <div style="color: #7F8C8D; font-size: 0.75em; margin-top: 4px;">TCP</div>
          </div>
          <div style="text-align: center;">
            <div style="color: #E67E22; font-size: 0.8em; font-weight: bold; margin-bottom: 4px;">${udpThroughput.toFixed(0)}</div>
            <div style="width: 50px; height: ${udpBarH}px; background: linear-gradient(180deg, #E67E22, #E74C3C); border-radius: 4px 4px 0 0;"></div>
            <div style="color: #7F8C8D; font-size: 0.75em; margin-top: 4px;">UDP</div>
          </div>
        </div>
      </div>
      <div style="background: white; border-radius: 8px; padding: 12px; text-align: center; min-width: 0;">
        <div style="color: #7F8C8D; font-size: 0.85em; margin-bottom: 8px;">Average Latency (ms)</div>
        <div style="display: flex; align-items: flex-end; justify-content: center; gap: 24px; height: 160px;">
          <div style="text-align: center;">
            <div style="color: #2C3E50; font-size: 0.8em; font-weight: bold; margin-bottom: 4px;">${tcpAvgLatency.toFixed(1)}</div>
            <div style="width: 50px; height: ${tcpLatBarH}px; background: linear-gradient(180deg, #3498DB, #2C3E50); border-radius: 4px 4px 0 0;"></div>
            <div style="color: #7F8C8D; font-size: 0.75em; margin-top: 4px;">TCP</div>
          </div>
          <div style="text-align: center;">
            <div style="color: #E67E22; font-size: 0.8em; font-weight: bold; margin-bottom: 4px;">${udpAvgLatency.toFixed(1)}</div>
            <div style="width: 50px; height: ${udpLatBarH}px; background: linear-gradient(180deg, #E67E22, #E74C3C); border-radius: 4px 4px 0 0;"></div>
            <div style="color: #7F8C8D; font-size: 0.75em; margin-top: 4px;">UDP</div>
          </div>
        </div>
      </div>
    </div>
    <div style="background: white; border-left: 4px solid ${recColor}; padding: 12px; border-radius: 4px;">
      <strong style="color: ${recColor};">IoT Recommendation:</strong>
      <span style="color: #2C3E50;"> ${recommendation}</span>
    </div>
  </div>`;
}

19.6.4 MAC Address Analyzer

Optional Sample Reading: MAC Address Analyzer

MAC address	OUI	Likely vendor	Address type	Lab interpretation
B8:27:EB:12:34:56	B8:27:EB	Raspberry Pi Foundation	Unicast, universal	Likely gateway or single-board computer.
DC:A6:32:AB:CD:EF	DC:A6:32	Espressif	Unicast, universal	Likely ESP32 or ESP8266 device.
00:1B:44:11:22:33	00:1B:44	Arduino	Unicast, universal	Likely development board or module.

Try It: MAC Address Analyzer

Enter a MAC address to parse its components. The first 3 bytes (OUI) identify the manufacturer, and the last 3 bytes (NIC) are the device-specific identifier. Try common IoT vendor prefixes like DC:A6:32 (Espressif/ESP32) or B8:27:EB (Raspberry Pi).

viewof macInput = Inputs.text({
  label: "MAC Address",
  value: "DC:A6:32:AB:CD:EF",
  placeholder: "XX:XX:XX:XX:XX:XX",
  width: 300
})

macAnalysis = {
  // Known IoT OUI database
  const ouiDB = {
    "DC:A6:32": { vendor: "Espressif Inc.", device: "ESP32 / ESP8266", color: "#E74C3C" },
    "AC:67:B2": { vendor: "Espressif Inc.", device: "ESP32-S2/S3/C3", color: "#E74C3C" },
    "B8:27:EB": { vendor: "Raspberry Pi Foundation", device: "Raspberry Pi", color: "#16A085" },
    "DC:A6:33": { vendor: "Espressif Inc.", device: "ESP32 Variant", color: "#E74C3C" },
    "D8:3A:DD": { vendor: "Raspberry Pi Trading Ltd", device: "Raspberry Pi 4/5", color: "#16A085" },
    "00:1B:44": { vendor: "Arduino LLC", device: "Arduino Board", color: "#3498DB" },
    "28:CD:C1": { vendor: "Arduino LLC", device: "Arduino MKR/Nano", color: "#3498DB" },
    "A4:CF:12": { vendor: "Espressif Inc.", device: "ESP32 Module", color: "#E74C3C" },
    "CC:50:E3": { vendor: "Espressif Inc.", device: "ESP32-WROOM", color: "#E74C3C" },
    "00:0D:B9": { vendor: "PC Engines GmbH", device: "IoT Gateway", color: "#9B59B6" },
    "00:17:88": { vendor: "Philips Lighting BV", device: "Hue Bridge/Bulb", color: "#E67E22" },
    "68:C6:3A": { vendor: "Samsung Electronics", device: "SmartThings Hub", color: "#2C3E50" }
  };

  // Parse the MAC address
  const cleaned = macInput.replace(/[^0-9A-Fa-f]/g, "").toUpperCase();
  const isValid = cleaned.length === 12 && /^[0-9A-F]{12}$/.test(cleaned);

  if (!isValid) {
    return html`<div style="background: #fdf2f2; border-left: 4px solid #E74C3C; padding: 16px; border-radius: 4px; font-family: Arial, sans-serif;">
      <strong style="color: #E74C3C;">Invalid MAC Address.</strong>
      <span style="color: #7F8C8D;"> Enter 6 hex bytes separated by colons (e.g., DC:A6:32:AB:CD:EF).</span>
    </div>`;
  }

  // Format the MAC
  const formatted = cleaned.match(/.{2}/g).join(":");
  const oui = formatted.slice(0, 8);
  const nic = formatted.slice(9);

  // Look up vendor
  const vendorInfo = ouiDB[oui] || { vendor: "Unknown Vendor", device: "Unknown Device", color: "#7F8C8D" };

  // Analyze bits
  const firstByte = parseInt(cleaned.slice(0, 2), 16);
  const isMulticast = (firstByte & 0x01) === 1;
  const isLocal = (firstByte & 0x02) === 2;

  // Binary representation of first byte
  const firstByteBin = firstByte.toString(2).padStart(8, "0");

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 20px; font-family: Arial, sans-serif;">
    <div style="text-align: center; margin-bottom: 16px;">
      <div style="font-size: 1.6em; font-family: monospace; letter-spacing: 2px; color: #2C3E50;">
        <span style="background: ${vendorInfo.color}22; padding: 4px 8px; border-radius: 4px; border-bottom: 3px solid ${vendorInfo.color};">${oui}</span>
        <span style="color: #7F8C8D; margin: 0 4px;">:</span>
        <span style="background: #7F8C8D22; padding: 4px 8px; border-radius: 4px; border-bottom: 3px solid #7F8C8D;">${nic}</span>
      </div>
      <div style="margin-top: 8px; font-size: 0.85em;">
        <span style="color: ${vendorInfo.color}; font-weight: bold;">OUI (Manufacturer)</span>
        <span style="color: #7F8C8D; margin: 0 16px;">|</span>
        <span style="color: #7F8C8D; font-weight: bold;">NIC (Device-Specific)</span>
      </div>
    </div>
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(150px, 1fr)); gap: 12px; margin-bottom: 16px;">
      <div style="background: white; border-left: 4px solid ${vendorInfo.color}; padding: 12px; border-radius: 4px;">
        <div style="color: #7F8C8D; font-size: 0.8em;">Vendor</div>
        <div style="color: #2C3E50; font-weight: bold;">${vendorInfo.vendor}</div>
        <div style="color: ${vendorInfo.color}; font-size: 0.85em;">${vendorInfo.device}</div>
      </div>
      <div style="background: white; border-left: 4px solid #3498DB; padding: 12px; border-radius: 4px;">
        <div style="color: #7F8C8D; font-size: 0.8em;">Address Type</div>
        <div style="color: #2C3E50; font-weight: bold;">${isMulticast ? "Multicast" : "Unicast"}</div>
        <div style="color: #3498DB; font-size: 0.85em;">${isLocal ? "Locally Administered" : "Universally Administered"}</div>
      </div>
    </div>
    <div style="background: white; padding: 12px; border-radius: 4px;">
      <div style="color: #7F8C8D; font-size: 0.8em; margin-bottom: 8px;">First Byte Binary Analysis (${cleaned.slice(0, 2)}h = ${firstByteBin}b)</div>
      <div style="font-family: monospace; font-size: 1.1em; display: flex; gap: 2px; justify-content: center;">
        ${firstByteBin.split("").map((bit, i) => {
          let bg = "#ecf0f1";
          let label = "";
          if (i === 6) { bg = isLocal ? "#E67E22" : "#16A085"; label = "U/L"; }
          if (i === 7) { bg = isMulticast ? "#E74C3C" : "#3498DB"; label = "I/G"; }
          return html`<div style="text-align: center;">
            <div style="width: 32px; height: 32px; background: ${bg}; color: ${(i === 6 || i === 7) ? 'white' : '#2C3E50'}; display: flex; align-items: center; justify-content: center; border-radius: 4px; font-weight: bold;">${bit}</div>
            <div style="font-size: 0.65em; color: #7F8C8D; margin-top: 2px;">${label || `b${7 - i}`}</div>
          </div>`;
        })}
      </div>
      <div style="margin-top: 8px; font-size: 0.8em; color: #7F8C8D; text-align: center;">
        <strong>I/G</strong> (bit 0): ${isMulticast ? "1 = Multicast" : "0 = Unicast"} |
        <strong>U/L</strong> (bit 1): ${isLocal ? "1 = Locally Administered" : "0 = Universally Administered (factory-set)"}
      </div>
    </div>
  </div>`;
}

19.7 Hands-On Labs

19.7.1 Lab 1: ESP32 Network Diagnostics Dashboard

Objective: Create a comprehensive network diagnostics tool on ESP32 that reports all network parameters.

Materials:

• ESP32 development board
• Wi-Fi network
• Serial monitor

Optional Diagnostics Dashboard Plan

Build the hardware dashboard as a set of small checks. Keep the serial output short enough that you can compare it with your lab notebook.

Check	ESP32 information to print	Healthy evidence	If it fails
Wi-Fi status	Connected/disconnected, SSID, channel	Connected to the intended 2.4 GHz network	Recheck SSID, WPA mode, and 2.4 GHz availability.
Signal	RSSI in dBm	Better than about -75 dBm	Move the device, improve antenna placement, or add an AP.
IP configuration	IP, subnet mask, gateway, DNS	IP is not 0.0.0.0 or 169.254.x.x; gateway and DNS are present	Check DHCP pool, VLAN, or router policy.
Hardware identity	MAC address	Stable address recorded in the inventory	Use it for DHCP reservation or asset tracking.
Connectivity	Gateway, DNS, and internet checks	Gateway reachable; DNS resolves; cloud test succeeds	Separate local routing, DNS, and internet firewall issues.

Optional Diagnostics Report Example

Section	Example result	Lab interpretation
Wi-Fi connection	Connected to MyHomeNetwork, channel 6, RSSI -45 dBm	Strong local link.
IP configuration	192.168.1.100, mask 255.255.255.0, gateway/DNS 192.168.1.1	DHCP produced a usable LAN configuration.
Hardware	MAC DC:A6:32:AB:CD:EF	Device can be identified in router logs.
Network information	Network 192.168.1.0, broadcast 192.168.1.255	Address belongs to the expected /24 subnet.
Connectivity tests	Gateway reachable, DNS working, internet access yes	The device is ready for cloud or broker traffic.

Learning Outcomes:

• Retrieve all network configuration parameters
• Perform connectivity diagnostics
• Understand Wi-Fi signal strength (RSSI)
• Calculate network and broadcast addresses
• Test DNS resolution and internet connectivity

Try It: Wi-Fi RSSI Signal Strength Visualizer

Explore how RSSI (Received Signal Strength Indicator) values map to real-world Wi-Fi quality. Drag the distance slider to simulate how signal degrades as an ESP32 moves farther from the access point, and see the impact on IoT data reliability.

viewof distanceM = Inputs.range([0.5, 50], {value: 5, step: 0.5, label: "Distance from AP (meters)"})
viewof wallCount = Inputs.range([0, 5], {value: 0, step: 1, label: "Walls between device and AP"})
viewof frequency = Inputs.select(["2.4 GHz", "5 GHz"], {value: "2.4 GHz", label: "Wi-Fi Frequency Band"})

rssiViz = {
  // Free-space path loss approximation + wall attenuation
  const freqGHz = frequency === "2.4 GHz" ? 2.4 : 5.0;
  const txPower = -30; // RSSI at 1 meter reference
  const pathLossExp = 2.8; // Indoor path loss exponent
  const wallLoss = wallCount * (frequency === "2.4 GHz" ? 3 : 5); // dB per wall
  const rssi = txPower - (10 * pathLossExp * Math.log10(distanceM)) - wallLoss;
  const rssiClamped = Math.max(-100, Math.min(-10, rssi));

  // Quality classification
  let quality, qualColor, qualDesc, reliabilityPct, iotImpact;
  if (rssiClamped > -50) {
    quality = "Excellent"; qualColor = "#16A085"; reliabilityPct = 99;
    qualDesc = "Strong signal. Reliable for all IoT applications including video streaming and OTA updates.";
    iotImpact = "All protocols work optimally: MQTT, HTTP, CoAP, WebSocket.";
  } else if (rssiClamped > -60) {
    quality = "Good"; qualColor = "#3498DB"; reliabilityPct = 95;
    qualDesc = "Solid signal. Suitable for most IoT use cases with minimal packet loss.";
    iotImpact = "MQTT and CoAP reliable. HTTP file transfers may slow slightly.";
  } else if (rssiClamped > -70) {
    quality = "Fair"; qualColor = "#E67E22"; reliabilityPct = 80;
    qualDesc = "Adequate signal. Some packet retransmissions likely. Consider antenna or placement optimization.";
    iotImpact = "MQTT QoS 1+ recommended. Reduce payload sizes. Increase retry timeouts.";
  } else if (rssiClamped > -80) {
    quality = "Poor"; qualColor = "#E74C3C"; reliabilityPct = 50;
    qualDesc = "Weak signal. Frequent disconnections and retransmissions expected.";
    iotImpact = "Use MQTT QoS 2 or local buffering. OTA updates will fail. Consider mesh networking.";
  } else {
    quality = "Unusable"; qualColor = "#7F8C8D"; reliabilityPct = 10;
    qualDesc = "Signal too weak for reliable communication. Device will frequently disconnect.";
    iotImpact = "Move device closer, add repeater/mesh node, or switch to LoRa for long range.";
  }

  // Signal bars (5 bars)
  const barsActive = rssiClamped > -50 ? 5 : rssiClamped > -60 ? 4 : rssiClamped > -70 ? 3 : rssiClamped > -80 ? 2 : rssiClamped > -90 ? 1 : 0;

  // SVG signal visualization
  const svgWidth = 600;
  const svgHeight = 120;

  // Position of AP and device
  const apX = 60;
  const devX = 60 + (distanceM / 50) * (svgWidth - 120);
  const centerY = 60;

  // Signal circles (emanating from AP)
  const circles = [0.2, 0.4, 0.6, 0.8].map((r, i) => {
    const radius = r * (svgWidth - 120) * 0.5;
    const opacity = Math.max(0.05, 0.3 - (i * 0.07));
    return `<circle cx="${apX}" cy="${centerY}" r="${radius}" fill="none" stroke="${qualColor}" stroke-width="1.5" opacity="${opacity}" stroke-dasharray="4,4"/>`;
  }).join("");

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 20px; font-family: Arial, sans-serif;">
    <div style="display: flex; align-items: center; justify-content: center; gap: 24px; margin-bottom: 16px;">
      <div style="text-align: center;">
        <div style="font-size: 2.4em; font-weight: bold; color: ${qualColor};">${rssiClamped.toFixed(0)} dBm</div>
        <div style="font-size: 1.1em; color: ${qualColor}; font-weight: bold;">${quality}</div>
      </div>
      <div style="display: flex; align-items: flex-end; gap: 3px; height: 40px;">
        ${[1,2,3,4,5].map(i => {
          const h = 8 + (i * 6);
          const active = i <= barsActive;
          return html`<div style="width: 8px; height: ${h}px; background: ${active ? qualColor : '#ddd'}; border-radius: 2px;"></div>`;
        })}
      </div>
    </div>
    <svg width="100%" viewBox="0 0 ${svgWidth} ${svgHeight}" style="background: white; border-radius: 8px; margin-bottom: 16px;">
      ${html([circles])}
      <!-- AP icon -->
      <rect x="${apX - 15}" y="${centerY - 20}" width="30" height="40" rx="4" fill="#2C3E50"/>
      <line x1="${apX}" y1="${centerY - 20}" x2="${apX}" y2="${centerY - 32}" stroke="#2C3E50" stroke-width="2"/>
      <circle cx="${apX}" cy="${centerY - 35}" r="3" fill="#16A085"/>
      <text x="${apX}" y="${centerY + 35}" text-anchor="middle" fill="#2C3E50" font-size="11" font-family="Arial">AP</text>
      <!-- Distance line -->
      <line x1="${apX + 20}" y1="${centerY}" x2="${devX - 20}" y2="${centerY}" stroke="${qualColor}" stroke-width="2" stroke-dasharray="6,4"/>
      <text x="${(apX + devX) / 2}" y="${centerY - 10}" text-anchor="middle" fill="#7F8C8D" font-size="10" font-family="Arial">${distanceM}m${wallCount > 0 ? ` + ${wallCount} wall${wallCount > 1 ? 's' : ''}` : ''}</text>
      <!-- ESP32 icon -->
      <rect x="${devX - 12}" y="${centerY - 14}" width="24" height="28" rx="3" fill="${qualColor}"/>
      <rect x="${devX - 8}" y="${centerY - 10}" width="16" height="14" rx="2" fill="white" opacity="0.3"/>
      <text x="${devX}" y="${centerY + 32}" text-anchor="middle" fill="#2C3E50" font-size="11" font-family="Arial">ESP32</text>
    </svg>
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(150px, 1fr)); gap: 12px; margin-bottom: 12px;">
      <div style="background: white; border-left: 4px solid ${qualColor}; padding: 12px; border-radius: 4px;">
        <div style="color: #7F8C8D; font-size: 0.8em;">Data Reliability</div>
        <div style="display: flex; align-items: center; gap: 8px; margin-top: 4px;">
          <div style="flex: 1; background: #ecf0f1; border-radius: 4px; height: 10px; overflow: hidden;">
            <div style="background: ${qualColor}; height: 100%; width: ${reliabilityPct}%; border-radius: 4px; transition: width 0.3s;"></div>
          </div>
          <span style="color: ${qualColor}; font-weight: bold; font-size: 0.9em;">${reliabilityPct}%</span>
        </div>
      </div>
      <div style="background: white; border-left: 4px solid #2C3E50; padding: 12px; border-radius: 4px;">
        <div style="color: #7F8C8D; font-size: 0.8em;">ESP32 Band</div>
        <div style="color: #2C3E50; font-weight: bold; margin-top: 4px;">${frequency}${frequency === "5 GHz" ? html` <span style="color: #E74C3C; font-size: 0.8em;">(ESP32 unsupported!)</span>` : ""}</div>
      </div>
    </div>
    <div style="background: white; padding: 12px; border-radius: 4px; margin-bottom: 8px;">
      <div style="color: #2C3E50; font-size: 0.9em;">${qualDesc}</div>
    </div>
    <div style="background: white; border-left: 4px solid #9B59B6; padding: 12px; border-radius: 4px;">
      <div style="color: #9B59B6; font-size: 0.8em; font-weight: bold;">IoT Protocol Impact</div>
      <div style="color: #2C3E50; font-size: 0.9em; margin-top: 4px;">${iotImpact}</div>
    </div>
  </div>`;
}

---

19.7.2 Lab 2: Python Advanced Network Scanner with Service Detection

Network Scanning Workflow

A simple IoT subnet scan follows the same five-step loop every time:

1. Expand the target range from CIDR notation such as 192.168.1.0/24 into candidate host addresses.
2. Probe for live hosts with ping or TCP reachability checks so you do not waste time on offline addresses.
3. Resolve names and roles using reverse DNS, MAC vendor hints, and known gateway addresses.
4. Scan common IoT ports such as 22, 80, 443, 1883, 5683, 8080, and 8883 to identify likely services.
5. Flag security findings when you discover plaintext HTTP or MQTT where TLS-enabled alternatives would be safer.

For beginner use, read the scanner output as a map: who is online, what service each device exposes, and which devices need hardening.

Objective: Build a network scanner that identifies IoT devices by detecting open ports and services.

Materials:

• Python 3.7+
• Local network access

Optional Sample Reading: Advanced Scanner

Device	Services found	Security note	What to do next
192.168.1.1 router	HTTP, HTTPS	Management interface is exposed locally	Confirm admin password and restrict access.
192.168.1.100 ESP32 sensor	HTTP, MQTT, alternate HTTP	Plain HTTP and MQTT are visible	Prefer HTTPS and MQTT/TLS for production.
192.168.1.150 Raspberry Pi	SSH, HTTP, HTTPS, MQTT	Mixed secure and insecure services	Keep SSH patched; move MQTT to TLS if sensitive.

Learning Outcomes:

• Perform service detection and port scanning
• Identify common IoT protocols
• Detect security vulnerabilities
• Use concurrent programming for efficiency
• Understand service banners

19.8 Additional Visual References

Visual: IoT Networking Stack

IoT networking stack showing protocol layers

Understanding the complete IoT networking stack helps developers see how protocols at different layers interact during device communication.

Visual: Connectivity Metrics

Network connectivity metrics for IoT performance evaluation

Key metrics for evaluating IoT network performance: RSSI for signal quality, latency for responsiveness, throughput for data capacity, and packet loss for reliability.

Visual: Wi-Fi Module Architecture

Wi-Fi module internal architecture

Understanding Wi-Fi module architecture helps developers configure and troubleshoot wireless connectivity in ESP32 and similar IoT platforms.

Visual: Wi-Fi Mesh Network

Wi-Fi mesh network topology

Wi-Fi mesh networks extend coverage beyond single access point range, providing redundant connectivity paths ideal for large IoT deployments.

Visual: 802.11 Channel Access

802.11 CSMA/CA channel access mechanism

The 802.11 CSMA/CA mechanism ensures fair channel access among multiple wireless devices, essential knowledge for debugging Wi-Fi connectivity issues in dense IoT deployments.

Decision Framework: Choosing Static vs DHCP for Production IoT

This decision matrix helps you determine the optimal IP addressing strategy for different IoT device types:

Device Type	Static IP	DHCP	DHCP Reservation	Rationale
MQTT Broker	Best	No	Acceptable	Fixed address required by all clients; DNS adds complexity; static = zero dependencies
IoT Gateway	Best	No	Good	Port forwarding rules need predictable address; reservation provides flexibility + stability
Security Cameras	Acceptable	No	Best	NVR needs stable addresses; reservation enables mass deployment without manual config per camera
Mobile Robots	No	Best	No	Devices roam between APs; dynamic assignment handles mobility; static would require manual changes per zone
Temperature Sensors	No	Best	Optional	100+ sensors = manual config nightmare; DHCP auto-provisions; reservations useful for critical zones only
Industrial PLCs	Required	No	No	Safety-critical control systems must function even if DHCP server fails; static guarantees deterministic addresses
Development/Test Devices	No	Best	No	Frequent additions/removals; DHCP prevents IP conflicts; no production dependencies

Decision Rules:

Question	If yes	If no
Is the device safety-critical or infrastructure?	Prefer static IP unless central reservation is required.	Continue to scale and mobility questions.
Does it need external port forwarding?	Use DHCP reservation for stable addressing with easier management.	Static IP is acceptable for small infrastructure devices.
Does the fleet exceed about 50 devices?	Use DHCP automation.	Reservation or static addressing can be manageable.
Will the device move between networks?	Use DHCP.	DHCP reservation gives predictable addresses without manual device edits.

Configuration Choices:

Method	What you configure	When to use it	Risk to watch
Static IP on device	IP, gateway, subnet, DNS in firmware	Safety-critical fixed equipment	Manual errors and duplicate addresses.
DHCP default	Device asks the network for settings	Mobile, test, and large sensor fleets	Address can change unless tracked by hostname or inventory.
DHCP reservation	Router maps MAC address to fixed IP	Gateways, cameras, brokers, and managed fleets	Requires accurate MAC inventory.

Hybrid Strategy for Real Deployments:

Building Automation Example (500 devices):

Range	IP Addresses	Purpose
Static	192.168.10.1 – 192.168.10.50	Gateway (.1), MQTT broker (.10), NTP server (.11), Backup gateway (.2)
DHCP Reservation	192.168.10.51 – 192.168.10.150	Security cameras (.51-.70), Access control panels (.71-.80), HVAC controllers (.81-.95)
DHCP Dynamic Pool	192.168.10.151 – 192.168.10.254	Temperature sensors (400+), Development devices, Guest maintenance laptops

Putting Numbers to It

For a 500-device building automation deployment using 192.168.10.0/24:

Address allocation math: $ = 2^8 = 256 $ $ = 256 - 2 = 254 $ $ = 50, (1-50) $ $ = 100, (51-150) $ $ = 104, (151-254) $

IP address utilization: $ = 4, = = 8% $ $ = 45, = = 45% $ $ = 450, = % $

The dynamic pool is oversubscribed by 4.3x, which works because not all 450 sensors are online simultaneously. With a 10% simultaneous connection rate, only ~45 sensors need DHCP leases at once, fitting comfortably in the 104-address pool. This demonstrates the efficiency of DHCP for large sensor deployments – 450 devices share 104 addresses via lease rotation.

Troubleshooting Decision Table:

Problem	Static IP	DHCP	DHCP Reservation
Device won’t connect	Check IP conflict (ping first), subnet mask, gateway	Check DHCP server status, lease availability	Check MAC address correct in reservation
Intermittent connectivity	Non-issue (address is fixed)	Check lease time (too short?), DHCP server reliability	Check reservation not conflicting with static range
Can’t reach device remotely	Firewall/NAT config issue	Device IP changed – check DHCP logs	Reservation correct but port forwarding not updated
Device moved to new network	Requires manual reconfiguration (firmware update or console access)	Works immediately	Requires new reservation on new network

Key Metrics to Track:

Method	IP Conflict Rate	Time to Provision	Mean Time to Resolve
Static IP	Target < 0.1% (requires tracking spreadsheet)	~10 min (manual config)	~30 min (manual troubleshooting)
DHCP	~0% (server prevents conflicts)	~30 sec (plug in and power on)	~5 min (check DHCP logs)
DHCP Reservation	~0% (managed by DHCP)	~2 min (add MAC reservation, then deploy)	~10 min (verify reservation DB)

Security Implications:

Method	DHCP Snooping	IP Source Guard	DAI Support	MAC Filtering
Static IP	Compatible	Compatible	Compatible	Manual ACLs required
DHCP	Essential	Essential	Essential	MAC changes break reservation
DHCP Reservation	Optimal	Optimal	Optimal	Reservation ties MAC to IP

Best Practice for Production IoT:

Use DHCP with reservations for 80% of devices (security cameras, sensors with known locations, gateways), static IP for 15% (critical infrastructure like brokers, NTP, DNS), and pure DHCP for 5% (test devices, temporary maintenance equipment).

This provides the “best of both worlds”: central management via DHCP server + address predictability via reservations + maximum reliability for critical infrastructure via static.

19.9 Interactive Review Activities

19.9.1 Match IoT Network Concepts

19.9.2 Sequence: ESP32 Cold Boot to Data Ready

Common Pitfalls

1. Memorising Lab Results Without Understanding Them

Writing down measured values without being able to explain why they differ from theoretical predictions scores poorly on post-lab analysis questions. Fix: for every measurement that differs from theory by more than 10%, write one sentence explaining the physical reason for the discrepancy.

2. Completing the Lab and Then Attempting the Quiz Without Reviewing Notes

Lab details fade quickly. Fix: review lab notes and sketched diagrams immediately after completing the lab, before moving on to the quiz.

3. Treating the Quiz as Separate From the Lab

Quiz questions about lab exercises test comprehension of what you observed and why. Generic textbook knowledge without reference to the specific lab measurements earns partial credit only. Fix: answer quiz questions with specific reference to your own lab measurements and observations.

19.9.3 Label the Diagram

19.9.4 Code Challenge

19.10 Summary

• Wi-Fi connectivity for IoT devices requires configuring SSID credentials, retrieving network parameters (IP address, gateway, DNS), and monitoring connection status using libraries like the ESP32 WiFi.h library
• Network information retrieval enables devices to programmatically access IP addresses, MAC addresses, subnet masks, gateway addresses, and signal strength (RSSI) for diagnostics and troubleshooting
• IP address calculations involve determining network addresses, broadcast addresses, and usable host ranges using subnet masks, with the formula: usable hosts = 2^(32 - prefix) - 2
• Network scanning discovers active devices on a subnet by probing ports and services, identifying IoT protocols like MQTT (1883), CoAP (5683), HTTP (80/443), and SSH (22) to map network topology
• Protocol performance varies significantly between TCP and UDP, with TCP providing reliable delivery through retransmissions at the cost of higher latency, while UDP offers lower latency with potential packet loss
• MAC address analysis reveals device manufacturers through OUI (Organizationally Unique Identifier) lookups and identifies address types (unicast vs multicast, universal vs locally administered)
• Security considerations include detecting insecure services (Telnet, unencrypted HTTP/MQTT), implementing TLS encryption (HTTPS on 443, MQTT/TLS on 8883), and proper firewall configuration
• IP addressing strategy (static, DHCP, or DHCP reservations) should match device criticality, deployment scale, and mobility requirements

19.11 What’s Next

After completing these hands-on labs and quizzes, you are ready to explore more advanced networking topics and protocols:

• Network Mechanisms: Network Mechanisms explains packet switching, datagrams, and bandwidth-versus-throughput trade-offs.
• Layered Network Models: Layered Network Models revisits OSI, TCP/IP, and encapsulation with more depth.
• Routing Fundamentals: Routing Fundamentals covers path selection and forwarding decisions between networks.
• MQTT Fundamentals: MQTT Fundamentals applies these connectivity skills to publish-subscribe messaging.
• Transport Fundamentals: Transport Fundamentals compares TCP and UDP in more detail for IoT workloads.
• Wi-Fi IoT Implementations: Wi-Fi IoT Implementations extends the ESP32 work into OTA, WPA3, provisioning, and mesh networking.

19.12 Knowledge Check

Test your understanding of network configuration, addressing, scanning, and protocol performance with these questions.

Auto-Gradable Quick Check

Understanding Check: Wi-Fi Troubleshooting for ESP32 Fleet

Scenario: You have deployed 50 ESP32 environmental monitors across a 3-story office building. After 2 weeks, 15 devices (30%) stop connecting to Wi-Fi. The others work fine.

Initial Assumptions (All Wrong):

• “Wi-Fi password must have changed” – No, 35 devices still connect fine
• “ESP32 Wi-Fi is unreliable” – No, same hardware works elsewhere
• “Interference from new equipment” – No, happens on all floors randomly

Systematic Troubleshooting (Flowchart-Based):

Step 1: Can ESP32 see network? Run WiFi.scanNetworks() on failed device – Found 12 networks, including target SSID

Step 2: Correct password? Check code: const char* password = "OfficeWiFi2024!" – Matches router

Step 3: 2.4 GHz network? Router shows: “Office_5GHz” and “Office_2.4GHz” – Failed devices use “Office_5GHz”

Root Cause Found: 15 ESP32s were configured to join the 5 GHz SSID even though standard ESP32 Wi-Fi only supports 2.4 GHz. The 35 working devices used the 2.4 GHz SSID.

Why This Happened:

• IT upgraded office Wi-Fi, adding a 5 GHz band
• New “Office_5GHz” SSID advertised prominently
• A technician configured 15 replacement ESP32s with the visible 5 GHz SSID
• ESP32 sees 5 GHz beacons but cannot associate (hardware limitation: 2.4 GHz radio only)

The Fix:

Before	After	Why it works
Device attempted Office_5GHz	Device uses Office_2.4GHz	ESP32 can associate with 2.4 GHz networks.
Failure message was vague	Serial output prints attempted SSID and band hint	The next technician can diagnose the issue without guessing.
Fleet inventory did not track SSID choice	Lab notebook records SSID, RSSI, IP, and firmware version	Repeat failures become searchable evidence.

Lessons Learned:

1. ESP32 limitation: Standard ESP32 supports 2.4 GHz only (no 5 GHz, no Wi-Fi 6E)
2. Dual-band confusion: Devices see 5 GHz beacons but cannot decode/associate with them
3. Silent failure: No error message from the library, just a connection timeout
4. Diagnostic value: WiFi.scanNetworks() reveals what the device sees vs what it can use

Design Principle: Always verify device Wi-Fi capabilities before deployment. Document which SSIDs are 2.4 GHz vs 5 GHz. Add runtime diagnostics to IoT firmware for remote troubleshooting.

Question 1: Subnet Mask Calculation

A network has IP 192.168.10.0 with subnet mask 255.255.255.192 (/26). How many usable host addresses are available, and what is the broadcast address?

Answer:

Calculation steps:

1. Subnet mask analysis: 255.255.255.192 = /26 (26 network bits, 6 host bits)
2. Total addresses: 2^6 = 64 addresses per subnet
3. Usable hosts: 64 - 2 = 62 usable host addresses (subtract network and broadcast)
4. Subnet increment: 256 - 192 = 64

For 192.168.10.0/26:

• Network address: 192.168.10.0
• First usable host: 192.168.10.1
• Last usable host: 192.168.10.62
• Broadcast address: 192.168.10.63

This subnet size is ideal for small IoT deployments like a single building floor with 50-60 sensors.

Question 2: IP Addressing – Private vs Public

Why do most IoT devices use private IP addresses (192.168.x.x, 10.x.x.x) instead of public IPs?

Answer:

Private IP addresses are used for IoT devices because:

1. Address scarcity: Only ~4.3 billion IPv4 public addresses exist globally, far fewer than the billions of IoT devices
2. Security: Private IPs are not directly routable from the internet, providing a basic firewall
3. Cost: Public IPs require registration and often cost money from ISPs
4. Network flexibility: Private ranges allow organizations to design internal addressing freely

Private IP ranges (RFC 1918):

• 10.0.0.0/8 (16+ million addresses) – Large enterprises, smart cities
• 172.16.0.0/12 (1+ million addresses) – Medium organizations
• 192.168.0.0/16 (65,536 addresses) – Home networks, small buildings

NAT (Network Address Translation) allows private devices to access the internet by sharing a single public IP. However, NAT creates challenges for IoT: - Inbound connections are blocked (devices behind NAT cannot be directly reached) - Solutions: MQTT persistent connections, port forwarding, VPN tunnels

Question 3: Default Gateway Role

What is the role of a default gateway, and why is it essential for IoT devices to reach cloud servers?

Answer:

The default gateway is the router that forwards packets from local network devices to other networks (including the internet). When an IoT device needs to send data to a cloud server:

1. Device checks: “Is destination IP on my local subnet?” (using subnet mask)
2. If remote (different subnet): Send packet to default gateway
3. Gateway examines destination IP and forwards toward the target network
4. Packet may traverse multiple routers before reaching cloud server

Example:

• IoT sensor IP: 192.168.1.100/24
• Default gateway: 192.168.1.1
• Cloud server: 54.235.100.42

The sensor’s subnet mask (255.255.255.0) reveals that 54.235.100.42 is NOT in the 192.168.1.0/24 network, so the packet must go to the gateway.

IoT configuration essentials:

• IP address (device identity)
• Subnet mask (local network boundary)
• Default gateway (exit point for remote destinations)
• DNS server (resolve hostnames like mqtt.example.com)

Question 4: Port Numbers for IoT Protocols

What port numbers do common IoT protocols use, and why are they important?

Answer:

Port numbers identify specific services running on a device. Key IoT protocol ports:

Protocol	Port	Transport	Usage
MQTT	1883	TCP	Unencrypted messaging
MQTT/TLS	8883	TCP	Encrypted messaging
CoAP	5683	UDP	Constrained devices
CoAP/DTLS	5684	UDP	Secure constrained devices
HTTP	80	TCP	Web interfaces
HTTPS	443	TCP	Secure web
SSH	22	TCP	Remote device access
Modbus TCP	502	TCP	Industrial control

Why ports matter for IoT:

• Firewall rules: Must allow traffic on required ports (e.g., open 8883 for secure MQTT)
• Security scanning: Open ports reveal services; close unnecessary ones
• Service identification: Port 1883 open suggests MQTT broker
• Troubleshooting: Connection issues often relate to blocked ports

Security note: Always prefer encrypted variants (8883 over 1883, 5684 over 5683) in production deployments.