HS
Let’s Collaborate

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.

Duration: 120–180 minutesNative Python runnable labTest with Wireshark / Postman / n8n

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…
Start / health APIOpen live data endpointWorks with Postman + n8n HTTP Request

Native Python Testing Kit

Run the lab locally with Python only, then validate it using Postman requests, n8n automation, and Wireshark traffic evidence.

README / run guideLocal Postman collectionOnline Worker PostmanLocal n8n workflowOnline Worker n8nWireshark filters
Download generated Wireshark PCAP

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 teams

20 min

1. Capture orientation

Station 1

Identify endpoints, conversations, and protocol mix in a simulated IoT trace.

  1. List top talkers and destination ports.
  2. Filter DNS queries and identify broker/cloud endpoints.
  3. Separate control-plane traffic from sensor payload traffic.
  4. 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 2

Trace how a device finds and establishes a secure session with the cloud.

  1. Filter dns and identify lookup latency or repeated queries.
  2. Follow the TCP handshake and identify retransmissions.
  3. Locate TLS ClientHello and SNI where visible.
  4. Explain what TLS hides and what metadata remains visible.

Evidence:Annotated connection sequence diagram.

45 min

3. MQTT reliability experiment

Station 3

Compare MQTT QoS behavior when the sensor link is unstable.

  1. Filter mqtt and identify CONNECT, SUBSCRIBE, PUBLISH, PUBACK flows.
  2. Compare QoS 0 and QoS 1 delivery evidence.
  3. Explain retained messages and topic hierarchy.
  4. 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 4

Produce a defensible communication design for farmers, cloud operators, and maintainers.

  1. Score HTTP polling, MQTT, and UDP telemetry against reliability/security/overhead.
  2. Identify when not to use each protocol.
  3. Add monitoring metrics: retransmissions, broker disconnects, message age, packet loss.
  4. Present final recommendation with assumptions.

Evidence:Protocol decision matrix and architecture sketch.

Protocol evidence cards

ObservationLikely protocol clueRiskAction
Repeated name lookup before publishDNSDelay before data uploadCache broker address or inspect resolver
SYN followed by retransmissionTCPNetwork loss or blocked pathCheck route, firewall, signal quality
Payload unreadable but SNI visibleTLSEncrypted content limits inspectionUse endpoint logs plus metadata
PUBLISH without PUBACKMQTT QoS 1 problemAlert may not be confirmedReview broker/client retry settings
Fast datagram with no retryUDPLow overhead but weak delivery proofUse 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 1

Wireshark filter set

dns || mqtt || http || tls || tcp.analysis.retransmission
mqtt.msgtype == 3
tcp.port == 1883 || tcp.port == 8883

Self-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

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:

  1. Where does the communication path start failing?
  2. Which protocol behavior proves the failure?
  3. Which traffic remains visible when encryption is used?
  4. 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.