Build the core model
Read the lesson and connect each concept to the visual model above.
Deep lab purpose
This lab turns protocol theory into packet-level evidence. Students do not simply define DNS, TCP, UDP, HTTP, TLS, and MQTT. They inspect flows, isolate failures, compare trade-offs, and recommend a protocol architecture for a real IoT reliability problem.
Scenario
A smart-agriculture deployment monitors soil moisture and microclimate conditions. Farmers complain that alerts arrive late or not at all. The engineering team suspects unstable connectivity, poor topic design, mixed protocol choices, and weak monitoring.
Students must use Wireshark-style evidence to answer:
- Where does the communication path start failing?
- Which protocol behavior proves the failure?
- Which traffic remains visible when encryption is used?
- Which protocol choice best fits critical alerts versus routine telemetry?
Native Python + tool testing requirement
Students must run the provided native Python IoT protocol simulator, use Postman to publish telemetry and alerts, import the n8n workflow to poll protocol metrics, and open the generated PCAP in Wireshark. The lab is considered complete only when students can prove protocol behavior through API output plus packet evidence.
Required student artifacts
- Protocol inventory with endpoints, ports, filters, and observations.
- Annotated DNS → TCP → TLS connection sequence.
- MQTT QoS comparison notes with packet evidence.
- Troubleshooting decision tree for missing sensor alerts.
- Protocol decision matrix comparing HTTP polling, MQTT, UDP telemetry, and secure transport.
- Final architecture recommendation for the farming scenario.
Lab depth extension
For advanced classes, require teams to generate or capture traffic using Mosquitto and MQTT Explorer, then compare QoS 0 and QoS 1 behavior. If live capture is not possible, students can use the embedded evidence cards and simulate packet interpretation.
Instructor facilitation notes
Require students to cite display filters in every finding. A claim such as “MQTT is reliable” is not enough. Students must show what packet pattern proves or weakens that claim.
Challenge questions:
- Why is UDP attractive for some telemetry but dangerous for critical alerts?
- What does TLS hide, and what does it not hide?
- How would poor DNS behavior affect a sensor gateway?
- Why might HTTP polling waste bandwidth or power?
- Which metric should the operations team monitor after deployment?
Assessment emphasis
Strong submissions connect protocol mechanics to operational reliability. Weak submissions describe protocols generally without packet evidence or scenario-specific trade-offs.
Work with observable evidence
Use the lab to turn the lesson into a repeatable classroom exercise.
Scenario lab
A digital service is slow or unreliable, but the team has not isolated where the exchange fails.
Trace Interactive Deep Lab: Wireshark IoT Protocol Analysis from client request to service response and mark the verification boundary.- Focus
- communication protocol, wireshark, mqtt
- Evidence target
- An annotated exchange trace with observable signal, interpretation, and follow-up test.
Activity checklist
Write what you observed, what it means, and what should be verified next. This draft stays on this device.
Communication Protocol Interactive Lab
Wireshark + IoT Protocol Reliability Lab
Students troubleshoot an Indonesian smart-agriculture sensor network where soil-moisture alerts arrive late or disappear. They inspect DNS, TCP, UDP, HTTP, TLS, and MQTT evidence and recommend protocol changes.
Auto-start Worker Lab Runtime
When this page loads, it automatically calls the Cloudflare Worker runtime for this topic. Students can immediately test the online API in the browser, Postman, or n8n. The downloadable native Python version remains available for local execution and Wireshark loopback capture.
Live runtime status
Starting Worker runtime…
- Running endpoint diagnostics…
Native Python Testing Kit
Run the lab locally with Python only, then validate it using Postman requests, n8n automation, and Wireshark traffic evidence.
Learning outcomes
0% checked
Instructor toolkit
Roles
Packet analyst, IoT engineer, security reviewer, farm-operations owner, presenter.
Free tools
Wireshark, Mosquitto, MQTT Explorer, Python paho-mqtt, tcpdump, optional Docker.
Core filters
dns, tcp.analysis.retransmission, tls, mqtt, http, udp, ip.addr == x.x.x.x.
Design lens
Reliability, bandwidth, power use, security, observability, field maintenance.
Hands-on station board
Run in teams20 min
1. Capture orientation
Station 1Identify endpoints, conversations, and protocol mix in a simulated IoT trace.
20 min
1. Capture orientation
- List top talkers and destination ports.
- Filter DNS queries and identify broker/cloud endpoints.
- Separate control-plane traffic from sensor payload traffic.
- Record evidence screenshots with filter strings.
Evidence: Protocol inventory sheet with endpoint, port, filter, and observation.
35 min
2. DNS, TCP, and TLS chain
Station 2Trace how a device finds and establishes a secure session with the cloud.
35 min
2. DNS, TCP, and TLS chain
- Filter dns and identify lookup latency or repeated queries.
- Follow the TCP handshake and identify retransmissions.
- Locate TLS ClientHello and SNI where visible.
- Explain what TLS hides and what metadata remains visible.
Evidence: Annotated connection sequence diagram.
45 min
3. MQTT reliability experiment
Station 3Compare MQTT QoS behavior when the sensor link is unstable.
45 min
3. MQTT reliability experiment
- Filter mqtt and identify CONNECT, SUBSCRIBE, PUBLISH, PUBACK flows.
- Compare QoS 0 and QoS 1 delivery evidence.
- Explain retained messages and topic hierarchy.
- Recommend QoS level for moisture-alert vs periodic telemetry messages.
Evidence: MQTT decision table and packet screenshot set.
30 min
4. Protocol architecture recommendation
Station 4Produce a defensible communication design for farmers, cloud operators, and maintainers.
30 min
4. Protocol architecture recommendation
- Score HTTP polling, MQTT, and UDP telemetry against reliability/security/overhead.
- Identify when not to use each protocol.
- Add monitoring metrics: retransmissions, broker disconnects, message age, packet loss.
- Present final recommendation with assumptions.
Evidence: Protocol decision matrix and architecture sketch.
Protocol evidence cards
| Observation | Likely protocol clue | Risk | Action |
|---|---|---|---|
| Repeated name lookup before publish | DNS | Delay before data upload | Cache broker address or inspect resolver |
| SYN followed by retransmission | TCP | Network loss or blocked path | Check route, firewall, signal quality |
| Payload unreadable but SNI visible | TLS | Encrypted content limits inspection | Use endpoint logs plus metadata |
| PUBLISH without PUBACK | MQTT QoS 1 problem | Alert may not be confirmed | Review broker/client retry settings |
| Fast datagram with no retry | UDP | Low overhead but weak delivery proof | Use only for non-critical telemetry |
Copy-ready lab assets
Generate MQTT messages locally
mosquitto_sub -h test.mosquitto.org -t campus/farm/soil/#
mosquitto_pub -h test.mosquitto.org -t campus/farm/soil/moisture -m "plot=A1,value=27" -q 1Wireshark filter set
dns || mqtt || http || tls || tcp.analysis.retransmission
mqtt.msgtype == 3
tcp.port == 1883 || tcp.port == 8883Self-check quiz
1. Why might MQTT be preferred over repeated HTTP polling for IoT telemetry?
MQTT is designed for lightweight message distribution and delivery semantics.
2. What can Wireshark still reveal when TLS encrypts the payload?
Encryption hides content but not all traffic metadata.
Assessment rubric
Packet evidence
30%Findings include filters, packet numbers/screenshots, and accurate interpretation.
Protocol comparison
30%Trade-offs are concrete and tied to the smart-agriculture scenario.
Troubleshooting logic
25%Students distinguish symptoms, causes, and verification steps.
Communication clarity
15%Recommendation is understandable to technical and non-technical stakeholders.
Student deliverables
- ✓Wireshark evidence workbook
- ✓Annotated connection diagram
- ✓MQTT QoS experiment notes
- ✓Protocol decision matrix
- ✓Final architecture recommendation
Explain the decision
Confirm what you can observe, what remains uncertain, and what should happen next.
Before completing this lesson
- Name the input, decision point, and outcome shown in the visual.
- Identify one artifact that would count as evidence.
- State one limitation and one next verification step.