Chapters

19 Network Traffic Analysis: Evidence Paths

design-methodology
network
traffic
analysis

19.1 Start With the Decision

A packet trace proves only what its capture point can see. Place probes on both sides of the boundary that may fail.

19.2 Route Overview

This is part 1 of 2. Continue with Network Traffic Analysis: Capture Points and Tools.

19.3 Part Objectives

  • Trace capture paths that prove behavior across its components and failure boundaries.
  • Validate packet captures hold sensitive data with a concrete scenario and pass criteria.

19.4 Chapter Roadmap

  • Start With the Packet You Cannot Explain
  • Capture Paths That Prove Behavior
  • Build Readable Trace Bundles
  • Trace Visibility Has Limits
  • In 60 Seconds
  • Prerequisites
  • What This Chapter Adds
  • Turn Captures Into Evidence
  • Capture Planning
  • Packet Captures Hold Sensitive Data

19.5 Start With the Packet You Cannot Explain

Capture the Path That Can Explain the Failure

Picture a warehouse node that sometimes misses an alarm and then sends the same reading twice. A screen at the far end cannot show whether the delay began at the device, radio hop, edge box, wide-area link, message service, or app. The test lead must choose views that can separate those causes.

Write one question before collecting traffic. Name the event, expected path, allowed time, devices, clocks, software versions, and observation points. Decide which headers or logs can answer it and which content must stay hidden. Keep the capture command, filter, time zone, and scenario with the files.

Record a normal run, the failure, and a rerun after one change. Inject loss, delay, reconnect, a full queue, repeated messages, a bad clock, and a restarted service. Align evidence from at least two points. Check whether a missing packet was never sent, lost in flight, refused, delayed, or hidden after arrival.

Keep urgent local action independent of a remote path that the trace shows can miss its deadline. Traffic visibility does not grant permission to read private content or prove device trust. Redact and retain evidence under a named rule.

This opening does not teach every capture tool or expose encrypted content. Practitioner builds the question-led trace bundle. Under the Hood examines timing, retries, radio views, queues, clocks, encryption limits, and correlation.

Use this trace plan:

  • Name the failed act.
  • State the expected path.
  • Set the time bound.
  • Pick the first view.
  • Pick the next view.
  • Sync the test clocks.
  • Mark the test start.
  • Mark the test end.
  • Keep the test steps.
  • Keep the tool form.
  • Keep the code form.
  • Keep the time zone.
  • Save one sound run.
  • Save one failed run.
  • Lose one link once.
  • Delay one note once.
  • Repeat one note once.
  • Restart one hop once.
  • Line up both views.
  • Find the first gap.
  • State what stays hid.
  • Reopen after one change.

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.

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

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

A reliable Capture Paths That Prove Behavior review needs the figure Figure 19.1. Its Design Question and Capture Plan markers reveal where Traffic analysis is strongest when packet evidence closes a specific design or validation question enters the running decision.

Traffic analysis evidence loop from design question through capture plan, packet evidence, protocol review, simulation comparison, and design action.
Figure 19.1: Traffic analysis is strongest when packet evidence closes a specific design or validation question.

Follow Figure 19.1 from the design question to the capture plan, which sets the observation point, filter, and window. Packet evidence supports protocol review and model comparison before the team decides to pass, revise, or investigate.

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

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

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

19.10 Prerequisites

You should already be comfortable with:

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

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

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

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.

Pause at the figure Figure 19.2 before applying Packet Captures Hold Sensitive Data. Its packet evidence and Scope labels show why A capture plan keeps the trace tied to a question, a scope, and a stated evidence limit needs an evidence check for Packet Captures Hold Sensitive Data here.

IoT traffic analysis capture plan showing review question, observation point, capture scope, packet evidence, evidence limit, and review decision.
Figure 19.2: A capture plan keeps the trace tied to a question, a scope, and a stated evidence limit.

Read Figure 19.2 from left to right, starting with the question and observation point. Scope sets filters and endpoints before packets reveal sequences, timing, and retries. The evidence limit constrains the decision; changes to the question, path, or that limit require a retest.

19.14 Continue to the Next Part

Carry this evidence into Network Traffic Analysis: Capture Points and Tools, which begins with Capture Points.