14  Network Traffic Analysis

Turning Packet Captures Into Network Design Evidence

14.1 Start With the Packet You Cannot Explain

Imagine an installed node that sometimes misses alerts, reconnects slowly, or sends duplicate telemetry. Traffic analysis starts with that unexplained behavior and works backward through capture points, timestamps, loss, retries, encryption limits, and release evidence. The goal is not a pretty packet trace; it is a defensible explanation of what the system is doing.

14.2 Learning Objectives

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

• Plan network traffic captures that answer a design, validation, or troubleshooting question.
• Choose capture points for device, gateway, broker, RF, backhaul, and application evidence.
• Use packet traces to review protocol timing, retransmissions, loss, joins, retries, command traffic, and maintenance events.
• Explain how encryption changes what traffic analysis can and cannot prove.
• Package packet evidence so simulation results, field captures, and release decisions can be compared.

14.3 Capture Paths That Prove Behavior

Network traffic analysis is strongest when it starts with a behavior to explain, then chooses the path locations that can observe that behavior. The same stale alarm can look different at a device interface, an 802.15.4 sniffer, a LoRaWAN gateway, an MQTT broker, a cloud ingress point, and an application log. A device capture might show DNS delay and repeated TCP SYNs. A gateway capture might show backhaul jitter or NAT resets. A broker log might show session expiry, QoS acknowledgements, or a retained-message surprise. A cloud event stream might show that ingestion succeeded but dashboard freshness lagged.

For IoT design work, the goal is not to collect every packet. The goal is to capture the window where the design claim could fail: joining, reconnecting, retrying, roaming, commissioning, sending a burst, draining a queue, applying a command, or recovering after gateway/backhaul outage. A useful plan says which claim is being tested, which points can see it, which timestamps must align, which packet fields are enough, and which evidence remains outside the trace because of encryption, radio visibility, retention, or privacy limits.

Traffic analysis is strongest when packet evidence closes a specific design or validation question.

The evidence loop matters because packet files are easy to overread. A trace can prove that a gateway sent an MQTT PUBLISH at 09:14:03, that TCP retransmitted three segments, or that a LoRaWAN network server recorded weak SNR during a join wave. It cannot automatically prove why a sensor measurement was wrong, why a user did not acknowledge an alert, or why a cloud rule made a business decision. The design action is defensible only when the trace is linked to simulation assumptions, gateway logs, RF survey notes, broker telemetry, and the remaining uncertainty.

• Question: Join reliability, alarm freshness, retry storm, command latency, firmware update load, or broker disconnect.
• Viewpoint: Device NIC, RF sniffer, gateway, router, broker, cloud edge, or application event stream.
• Limit: Payload encryption, missed radio channels, NAT, clock drift, sampling window, retention policy, and privacy controls.

14.4 Build Readable Trace Bundles

A useful trace bundle includes the PCAP or flow export, the capture command, interface, channel, filter, time zone, clock source, device identifiers, software versions, scenario notes, and the logs needed for correlation. For gateways and Linux edge devices, that may mean tcpdump ring buffers, tshark extraction scripts, NTP status, broker logs from Mosquitto, EMQX, or HiveMQ, and application events from AWS IoT Core, Azure IoT Hub, OpenTelemetry, CloudWatch, or Azure Monitor. Keep the capture command and display filters with the evidence so another reviewer can reproduce the summary rather than trust screenshots.

Match the tool to the visibility problem. Wireshark is good for interactive protocol review. tshark is better for repeatable extraction in a test script. Nordic nRF Sniffer, TI SmartRF Packet Sniffer, Ubertooth, or an 802.15.4 capture dongle can expose BLE, Thread, Zigbee, or raw link behavior that an IP capture misses. ChirpStack, The Things Stack, or packet-forwarder logs can expose LoRaWAN join attempts, RSSI/SNR, frame counters, gateway id, and downlink timing when payloads stay encrypted. VPC flow logs, firewall logs, and cellular-router logs can be enough when the question is path reachability, volume, or backhaul timing rather than protocol fields.

Make the bundle decision-oriented. Label the baseline capture, the event capture, and any rerun after a design change. Record whether clocks were synchronized with NTP or PTP, whether capture offload features affected checksums, whether monitor-mode radios covered the right channel, and whether packet loss could have happened before the capture point. For sensitive traces, document redaction, key handling, retention, and who may access the raw PCAP. A reviewer should be able to open the bundle and see the scenario, observation point, visible protocol facts, missing evidence, and proposed action without reconstructing the test from memory.

1. Capture the symptom window. Include baseline plus the event: reboot, alarm burst, gateway loss, firmware rollout, handoff, or link degradation.
2. Keep correlation data. Align packet times with firmware logs, broker session ids, gateway counters, application events, and simulation run ids.
3. Summarize observable facts. Report MQTT CONNECT/CONNACK, PINGREQ/PINGRESP, QoS acknowledgements, CoAP ACK/RST, TCP retransmissions, resets, DNS timing, TLS or DTLS handshakes, queue depth, and retry counts.

14.5 Trace Visibility Has Limits

A packet capture proves what crossed the capture point during the selected window. It does not prove packets lost before that point, cloud processing after that point, or payload content hidden by TLS, DTLS, OSCORE, WPA, LoRaWAN keys, BLE link-layer encryption, or broker-side access controls. A TCP retransmission shows transport recovery, but the cause may be RF loss, buffer pressure, roaming, firewall state, broker overload, or backhaul jitter. A missing packet in one capture can mean the packet never existed, the capture point missed the channel, the filter was too narrow, or the clock alignment points to the wrong event window.

The under-the-hood skill is separating transport evidence from application meaning. MQTT QoS 1 PUBACK timing can show delivery acknowledgement at the broker path, but it does not prove a human saw an alert. A CoAP ACK can prove message exchange at the protocol layer, but it does not prove a sensor value was physically correct. LoRaWAN frame counters and RSSI/SNR can show link behavior, but payload meaning still needs device, network-server, or application context. BLE supervision timeouts, Thread parent changes, Wi-Fi roaming, and cellular reconnects each leave different evidence trails, so the capture point must match the mechanism under review.

Trace interpretation also has measurement mechanics. Network-interface offload can make local checksum fields look wrong even when transmitted packets were valid. Monitor-mode radios may miss frequency hops or channels outside the selected band. Packet-forwarder logs may round or normalize timestamps. Broker logs may show accepted sessions but not every dropped network packet. Flow logs aggregate events and can hide short retransmission bursts. Strong analysis names these limits, uses a second evidence source where the decision is important, and avoids turning one visible symptom into a system-wide conclusion.

• Timing state: Clock sync, capture start/stop, frame deltas, keepalive intervals, reconnect delay, and queue drain time.
• Protocol state: Session setup, acknowledgements, retransmission, route repair, reset behavior, topic flow, and command response.
• Residual uncertainty: What must be checked with RF survey data, device logs, broker telemetry, application records, or a controlled staging capture.

In 60 Seconds

Network traffic analysis turns actual packets into design evidence. A useful capture plan names the decision, chooses the right observation point, records filters and time windows, preserves packet traces, and compares observed behavior with the scenario model. Captures cannot always reveal encrypted payloads, but they can still show timing, endpoints, handshakes, retransmissions, resets, packet sizes, joins, and recovery behavior that simulations and dashboards often miss.

14.6 Prerequisites

You should already be comfortable with:

• Network Simulation Methodology: scenario packs, model boundaries, run packages, and validation records.
• Network Simulation Tools: how simulation, emulation, capture, survey, and telemetry tools fit different evidence needs.
• Networking basics: packets, addressing, routing, transport, and application protocols.
• Application protocols: MQTT, CoAP, HTTP, publish/subscribe, request/response, and gateway patterns.

14.7 What This Chapter Adds

Simulation predicts behavior under model assumptions. Traffic analysis checks what actually happened on a device, link, gateway, broker, or backhaul path. This chapter focuses on using traffic analysis as design evidence, not as a generic tool tutorial.

Question

Evidence first

Start with the design, validation, security, or troubleshooting decision the capture must support.

Viewpoint

Capture point matters

A device, gateway, RF sniffer, broker, or cloud edge may each see different parts of the same failure.

Limits

Payloads may be opaque

TLS, DTLS, link-layer keys, and broker-side security can hide content while leaving timing and metadata visible.

Record

Traces need context

Packet files are useful only when tied to time windows, filters, devices, scenario events, and decision criteria.

14.8 Turn Captures Into Evidence

Network traffic analysis starts with a question, not a packet file. The team chooses the capture point that can observe the behavior, records the scenario window and filters, reads packet timing against protocol expectations, compares the trace with simulation or logs, and turns the result into a design action.

The loop introduced in the overview connects field evidence back to the scenario pack. It should tell reviewers what was captured, why it was captured, what it proves, and what remains outside the capture.

1. Design questionName the behavior that must be checked: join reliability, alarm freshness, retry storms, broker disconnects, route repair, or update traffic.

2. Capture planChoose observation points, filters, time windows, device identifiers, scenario events, and privacy controls.

3. Packet evidencePreserve PCAP files, capture commands, sniffer settings, clocks, labels, and analysis scripts.

4. Protocol reviewInspect timing, handshakes, acknowledgements, retransmissions, resets, queueing, joins, commands, and payload visibility.

5. Model comparisonCompare traces with simulation assumptions, gateway logs, RF survey results, and application telemetry.

6. Design actionState whether the design passes, needs investigation, needs revision, or needs another capture point.

14.9 Capture Planning

A capture without a question often becomes a large file that nobody can review. Plan the capture like an experiment.

Plan Item

What to Record

Why It Matters

Weak Evidence Looks Like

Question

The behavior or decision being checked.

Prevents unfocused capture and cherry-picked interpretation.

“Capture everything and look around.”

Capture point

Device interface, gateway, RF channel, broker, router, cloud edge, or application endpoint.

Different points can see different symptoms and hide different details.

Only the easiest point, with no explanation.

Scenario window

Baseline, alarm burst, join wave, gateway reboot, link degradation, firmware update, or recovery period.

IoT failures often appear during events, not quiet operation.

Only a calm steady-state sample.

Filters

Capture filters, display filters, device IDs, MAC/IP addresses, ports, protocol names, and topic names when visible.

Supports repeatable review without storing unrelated traffic.

Screenshots without the filters used.

Time and clocks

Clock source, time zone, capture start and stop times, event timestamps, and log alignment.

Correlation fails when traces, logs, and simulations use inconsistent time references.

“Around the time it failed.”

Privacy and keys

Payload sensitivity, decryption policy, redaction plan, key handling, and retention limits.

Packet traces can contain credentials, identifiers, location, and personal data.

Uploading raw PCAPs with no review.

Packet Captures Hold Sensitive Data

Treat PCAP files as evidence with access controls. They may include tokens, device IDs, locations, topic names, DNS names, certificate details, or plaintext payloads in development networks. Redact or restrict traces before sharing broadly.

A capture plan keeps the trace tied to a question, a scope, and a stated evidence limit.

14.10 Capture Points

Capture point selection controls which parts of the network behavior are visible.

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.

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

Protocol-specific capture choices keep the tool matched to the question being reviewed.

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

Use Documentation With Captures

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.

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

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

Keep Production Security Strong

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.

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

14.15 Incremental Examples

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

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

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

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

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

14.18 Micro-Exercise: Pick the Capture Point

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

1. A sensor publishes locally, but no alert appears in the dashboard.
2. Several Thread nodes go stale after a router is power-cycled.
3. 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.

14.19 Practice Checks

Match Capture Point to Evidence

Order Traffic Analysis Route

Label Traffic Evidence Loop

Concept Check: Capture Evidence

Concept Check: Encrypted Evidence

14.20 Common Pitfalls

1. Capturing Without a Decision Question

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

2. Capturing at the Wrong Point

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.

3. Ignoring Scenario Timing

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

4. Reporting Only Screenshots

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

5. Overclaiming Encrypted Captures

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

6. Forgetting Privacy and Retention

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

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

14.22 References

• Wireshark User’s Guide - official Wireshark packet-analysis documentation.
• Wireshark Display Filter Reference - official display-filter reference.
• tcpdump Manual Page - official tcpdump capture options.
• tshark Manual Page - official command-line Wireshark documentation.
• MQTT Version 5.0 Specification - official OASIS MQTT specification.
• RFC 7252: The Constrained Application Protocol - official CoAP specification.

14.23 See Also

• Network Simulation Methodology: compare field traces with scenario packs, model boundaries, and acceptance bands.
• Network Simulation Tools: choose when to use simulation, emulation, capture, survey, or telemetry evidence.
• Network Design Methodology: connect traffic findings to network design decisions.
• Testing and Validation: turn packet evidence into repeatable validation criteria.

14.24 What’s Next

If you want to…	Read this
Turn packet findings into validation criteria	Testing and Validation
Compare traces with scenario assumptions	Network Simulation Methodology
Choose the right evidence tool for a study	Network Simulation Tools
Translate evidence limits into component checks	Specification Sheet Fundamentals

Previous	Current	Next
Simulation Methods & Scenarios	Network Traffic Analysis	Specification Sheet Fundamentals

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