Chapters

20 Network Traffic Analysis: Capture Points and Tools

design-methodology
network
traffic
analysis

20.1 Start With the Decision

A device trace and an RF trace expose different faults. Choose the point that can observe the claim under test.

20.2 Route Overview

This is part 2 of 2. Review Network Traffic Analysis: Evidence Paths for the preceding evidence.

20.3 Learning Objectives

  • Test capture points with a concrete scenario and pass criteria.
  • Validate references with a concrete scenario and pass criteria.

20.4 Chapter Roadmap

  • Capture Points
  • Tool Roles
  • Use Documentation With Captures
  • Reading a Trace
  • Encryption and Evidence Limits
  • Keep Production Security Strong
  • Comparing Traffic With Simulation
  • Incremental Examples
  • Broker Disconnect Evidence
  • Try It Now
  • Micro-Exercise: Pick the Capture Point
  • Practice Checks
  • Match Capture Point to Evidence
  • Order Traffic Analysis Route
  • Label Traffic Evidence Loop
  • Concept Check: Capture Evidence
  • Concept Check: Encrypted Evidence
  • Common Pitfalls
  • 1. Capturing Without a Decision Question
  • 2. Capturing at the Wrong Point
  • 3. Ignoring Scenario Timing
  • 4. Reporting Only Screenshots
  • 5. Overclaiming Encrypted Captures
  • 6. Forgetting Privacy and Retention
  • Summary
  • References
  • See Also
  • What’s Next
  • Key Takeaway

20.5 Capture Points

The next Capture Points decision depends on the diagram Figure 20.1. Reading Device Interface against RF Sniffer clarifies the practical meaning of Capture point selection controls which parts of the network behavior are visible.

IoT traffic capture points at device, RF link, gateway, broker, cloud edge, and application log, each with different evidence visibility.
Figure 20.1: Capture point selection controls which parts of the network behavior are visible.

Follow Figure 20.1 from Device Interface into RF Sniffer before checking Gateway. The first highlights Device Interface, the second highlights RF Sniffer, and the last uses Gateway to locate a communication boundary. This ordered reading preserves Capture point selection controls which parts of the network behavior are visible in the Capture Points evidence chain.

Choose the capture point that can observe the evidence needed for the decision.

Capture Point
Best For
Common Blind Spot
Evidence Artifact
Device interface
Firmware timing, DNS, TCP or UDP setup, TLS handshake, publish or request cadence, and local retries.
May not see RF loss, gateway queueing, or broker-side behavior.
PCAP, serial log, firmware log, or local capture command.
RF sniffer
Over-the-air frames, channel behavior, join attempts, link-layer retries, acknowledgements, and weak locations.
Encrypted link payloads and missed channels can limit interpretation.
Sniffer PCAP, channel setting, device identifiers, and key policy.
Gateway
Device aggregation, translation behavior, routing, NAT, broker connections, local queues, and backhaul events.
May not see the original RF frame or cloud-side processing.
tcpdump or tshark capture, gateway logs, queue metrics.
Broker or server
Session behavior, authentication, topic flow, connection churn, QoS exchange, and command response.
Does not prove what happened on the radio or device before the broker saw traffic.
Broker logs, packet capture, access logs, and topic audit.
Network edge
Firewall, NAT, DNS, TLS, VPN, cellular, proxy, and backhaul path behavior.
Application payloads are often encrypted or aggregated.
Flow logs, packet capture, DNS logs, and firewall events.
Application telemetry
Business event timing, missing reports, command outcomes, and user-visible symptoms.
Does not reveal packet-level causes by itself.
Application logs, dashboards, event exports, and incident timelines.

20.6 Tool Roles

Do not rank tools in the abstract. Choose the tool role that matches the capture point and review question.

Wireshark

Interactive protocol review

Use for packet dissection, timeline inspection, stream following, field exploration, and training reviewers on what the trace shows.

tcpdump

Remote packet capture

Use on gateways, routers, Linux devices, and field systems where a lightweight command-line capture is practical.

tshark

Repeatable extraction

Use for scripted field extraction, test automation, CI checks, and producing repeatable summaries from PCAP files.

RF sniffer

Wireless link evidence

Use for 802.15.4, Thread, Zigbee, BLE, or other over-the-air behavior when gateway logs cannot show the radio exchange.

Flow logs

Aggregate path evidence

Use when packet payloads are unnecessary and the question is about endpoints, volume, timing, or backhaul behavior.

Application logs

Outcome correlation

Use to connect packets with commands, alerts, dashboards, user events, and incident timelines.

Before Tool Roles, inspect the figure Figure 20.2. Compare Protocol Capture Decision Tree with Packet-level analysis; their difference reveals Protocol-specific capture choices keep the tool matched to the question being reviewed. This gives Tool Roles evidence to revisit.

Protocol capture decision tree showing TCP/IP debugging with Wireshark, MQTT topic and payload analysis with MQTT Explorer, and LoRaWAN RF troubleshooting with gateway logs.
Figure 20.2: Protocol-specific capture choices keep the tool matched to the question being reviewed.

Read Figure 20.2 from Protocol Capture Decision Tree to Packet-level analysis, then finish at topics/payloads?. The Protocol Capture Decision Tree marker uses Protocol Capture Decision Tree to mark a decision point; Packet-level analysis uses Packet-level analysis to show the next hand-off; topics/payloads? uses topics/payloads? to show the next hand-off. For Tool Roles, that order makes Protocol-specific capture choices keep the tool matched to the question being reviewed a traceable decision.

20.6.1 Minimal Capture Examples

Use command snippets as starting points, not as unreviewed production procedures.

# Capture one device's broker traffic on a gateway.
sudo tcpdump -i eth0 host 192.0.2.40 and port 8883 -w device-broker.pcap

# Extract a repeatable packet summary from an existing capture.
tshark -r device-broker.pcap -Y "tcp.analysis.retransmission or tcp.flags.reset == 1" \
  -T fields -e frame.time -e ip.src -e ip.dst -e tcp.stream -e _ws.col.Info

Useful display filters depend on the protocol and visibility:

mqtt
coap
tcp.analysis.retransmission
tcp.flags.reset == 1
dns or mdns
ip.addr == 192.0.2.40
frame.time_delta > 1

The capture file alone is not enough evidence. Store the command, interface, filters, clock source, scenario description, device identifiers, tool versions, and analysis script beside the PCAP.

20.7 Reading a Trace

The strongest traffic analysis reports behavior, not just packets. Focus on patterns that connect to the design decision.

Pattern
What to Look For
Design Interpretation
Cross-Check
Handshake
DNS, TCP, TLS, DTLS, MQTT CONNECT, CoAP request setup, broker CONNACK, or join exchange.
Failures here point to addressing, credentials, certificate, broker, firewall, or join-policy problems.
Device logs, broker logs, DNS logs, certificate status, and gateway capture.
Cadence
Periodic reports, keepalive timing, command timing, sleep/wake windows, and event bursts.
Mismatch between firmware timing and protocol expectations can cause disconnects or stale data.
Firmware logs, application events, and simulation traffic model.
Loss and retry
Retransmissions, duplicate messages, acknowledgements, retry limits, backoff, and missing responses.
High retry behavior can indicate weak links, congestion, queueing, broker pressure, or application timeouts.
RF survey, gateway counters, simulator traces, and route metrics.
Routing and path
Next hops, NAT, DNS answers, broker endpoint, gateway route, and backhaul changes.
Unexpected destinations or path changes can explain latency, policy failures, or security findings.
Network configuration, firewall logs, route tables, and cloud access logs.
Payload visibility
Plaintext fields, encrypted application data, topic names, message sizes, and metadata.
Encryption may limit content review but still allow timing, size, endpoint, and session analysis.
Application logs, test keys, staged plaintext environment, or broker-side audit.

20.8 Encryption and Evidence Limits

Modern IoT traffic is often encrypted. That is usually correct. Traffic analysis should be honest about what remains visible and what needs another evidence source.

Visible Without Decryption
Usually Hidden
Evidence Strategy
Transport metadata
TCP or UDP timing, endpoints, ports, resets, retransmissions, packet sizes, and TLS or DTLS handshake metadata.
Application payload fields, MQTT topics inside TLS, CoAP payloads inside DTLS, and authenticated content.
Use timing and session evidence, then correlate with application or broker logs.
Development traces
Plaintext protocol fields in controlled test networks, local logs, and debug broker captures.
Production secrets, private payloads, and customer data should not be exposed just for convenience.
Use controlled staging captures and remove debug settings before production.
Key-assisted review
Decrypted test captures when session keys or test certificates are intentionally available.
Traffic protected by production keys should remain controlled by security policy.
Record key handling, retention, and who may access decrypted traces.

If encrypted traffic blocks payload inspection, use staged test captures, broker logs, device logs, or approved key logging. Do not ship weaker security because it makes packet analysis easier.

20.9 Comparing Traffic With Simulation

Traffic analysis is especially useful after simulation because it tests whether modeled assumptions match a field or pilot system.

Simulation Assumption
Traffic Evidence
Decision Impact
If They Disagree
Traffic cadence
Observed publish, request, command, keepalive, join, and update timing.
Checks whether the simulated workload matches real device behavior.
Update the traffic model or firmware timing assumption.
Retries and loss
Retransmissions, duplicate application messages, missing acknowledgements, retry bursts, and route repair.
Checks whether the model underestimates contention or weak links.
Add stress scenarios, RF evidence, or routing detail.
Fault recovery
Gateway reboot traces, reconnect timing, broker session behavior, route churn, and backlog drain.
Checks whether recovery time and command freshness remain acceptable.
Revise gateway, broker, backoff, or queue policy.
Maintenance load
Commissioning, key rotation, diagnostics, firmware update, and support traffic.
Checks whether release scenarios include operational traffic.
Add maintenance scenarios and operational runbooks.
Security posture
Encryption status, unexpected endpoints, DNS behavior, certificate handshake failures, and anomalous traffic shape.
Checks whether design assumptions align with security and privacy requirements.
Escalate to security review and update monitoring rules.

20.10 Incremental Examples

20.10.1 ESP32 MQTT Bench Capture

A lab team wants to confirm that an ESP32 temperature node publishes every 60 seconds to a local Mosquitto broker. The capture can run on the gateway or broker host with tcpdump, then be reviewed in Wireshark or summarized with tshark. The useful facts are the CONNECT/CONNACK timing, PUBLISH cadence, keepalive interval, DNS lookup, TCP reconnects, and whether the observed payload size and report interval match the simulation input.

20.10.2 Thread/Zigbee Join Wave

A room sensor pilot reports stale occupancy events after several nodes rejoin. The traffic-analysis plan should combine an 802.15.4 sniffer, gateway logs, and application timestamps during a planned join wave. A Nordic nRF Sniffer, TI SmartRF Packet Sniffer, or supported 802.15.4 capture dongle can expose frame timing, acknowledgements, route repair, and channel behavior, while gateway logs show what reached the IP side. The result should identify whether the stale event is caused by RF retries, route repair, gateway queueing, or broker/application delay.

20.10.3 Multi-Site Alarm Path Review

A facilities program needs to compare a simulation with field evidence from Wi-Fi gateways, LoRaWAN devices, and cellular backhaul. The capture bundle may include gateway tcpdump files, ChirpStack or The Things Stack metadata, packet-forwarder logs, MQTT broker session logs, AWS IoT Core or Azure IoT Hub events, OpenTelemetry traces, CloudWatch or Azure Monitor metrics, and Grafana dashboard timestamps. The review should separate radio link behavior, broker session behavior, cloud ingestion delay, dashboard freshness, and user acknowledgement so the team changes the correct layer.

20.11 Broker Disconnect Evidence

A pilot deployment reports that a device sometimes disappears from the dashboard even though firmware logs say the sensor is running.

QuestionIs the disconnect caused by the device, gateway, broker, backhaul, or dashboard path?
Capture planCapture at the gateway and collect broker logs during the next baseline and reconnect window.
Packet evidenceRecord DNS, TCP/TLS setup, MQTT session timing if visible, resets, retransmissions, and packet-size cadence.
Trace reviewFind whether packets stop at the device side, fail in the transport path, or reach the broker but fail application handling.
Cross-checkAlign the PCAP timeline with firmware logs, broker logs, and dashboard missing-data timestamps.
DecisionRevise firmware keepalive, gateway queueing, broker session policy, or monitoring based on the observed failure point.

A good result statement would not say “Wireshark fixed the issue.” It would say which capture point saw the last successful packet, which expected packet was absent or late, what logs agreed with the packet evidence, and which design assumption must change.

20.12 Try It Now

Rewrite this weak traffic-analysis result into a decision-ready statement:

“The packet capture looked normal, so the network is fine.”

A stronger answer should name the design question, capture point, scenario window, visible protocol facts, encrypted or missing evidence, related logs, and the design action that follows.

20.13 Micro-Exercise: Pick the Capture Point

For each symptom, choose the first capture point and one supporting log:

First: A sensor publishes locally, but no alert appears in the dashboard.

Next: Several Thread nodes go stale after a router is power-cycled.

Then: A cellular gateway reconnects after an outage, but commands arrive late.

Use device interface, RF sniffer, gateway, broker/server, network edge, or application telemetry as the capture point.

20.14 Practice Checks

Label Traffic Evidence Loop

20.15 Common Pitfalls

Large packet files are not automatically useful. Start with the behavior that must be verified or explained.

A broker capture cannot prove what happened on the radio, and an RF sniffer cannot prove cloud processing. Choose the capture point for the claim.

Quiet operation rarely explains failures caused by joins, gateway reboots, outage recovery, updates, or correlated alarms.

Screenshots can help a discussion, but a packet-analysis handoff needs PCAP files, commands, filters, timestamps, tool versions, and analysis notes.

Encrypted captures can show timing and session behavior, but they usually cannot prove application payload content without approved decryption or logs.

Packet traces may contain sensitive identifiers or payloads. Treat them as controlled evidence, not disposable screenshots.

20.16 Summary

Network traffic analysis validates what a network actually did. A strong traffic-analysis study starts with a decision question, chooses capture points intentionally, records filters and time windows, preserves packet evidence, reviews protocol behavior, states encryption limits, compares traces with simulation and logs, and ends with a design action. The goal is not to collect every packet. The goal is to collect the packets that can defend or revise the network design.

20.17 References

First: Wireshark User’s Guide - official Wireshark packet-analysis documentation.

Next: Wireshark Display Filter Reference - official display-filter reference.

Then: tcpdump Manual Page - official tcpdump capture options.

After that: tshark Manual Page - official command-line Wireshark documentation.

Also inspect: MQTT Version 5.0 Specification - official OASIS MQTT specification.

Finally: RFC 7252: The Constrained Application Protocol - official CoAP specification.

20.18 See Also

First: Network Simulation Methodology: compare field traces with scenario packs, model boundaries, and acceptance bands.

Next: Network Simulation Tools: choose when to use simulation, emulation, capture, survey, or telemetry evidence.

Then: Network Design Methodology: connect traffic findings to network design decisions.

After that: End-to-End Test Strategy: turn packet evidence into repeatable validation criteria.

20.19 What’s Next

If you want to…Read this
Turn packet findings into validation criteriaEnd-to-End Test Strategy
Compare traces with scenario assumptionsNetwork Simulation Methodology
Choose the right evidence tool for a studyNetwork Simulation Tools
Translate evidence limits into component checksSpecification Sheet Fundamentals
PreviousCurrentNext
Simulation Methods & ScenariosNetwork Traffic AnalysisSpecification Sheet Fundamentals

20.20 Key Takeaway

Traffic analysis turns device behavior into network load. Estimate message rate, payload size, overhead, retries, bursts, and gateway fan-in before assuming a network can scale.

20.21 Continue Your Route

This final part closes the route from Capture Points through Key Takeaway. Return to Network Traffic Analysis: Evidence Paths or continue from the design-methodology module index.