20 Network Traffic Analysis: Capture Points and Tools

20.1 Start With the Decision

This section: Start With the Decision — A device trace records what the device sends or receives.

A device trace records what the device sends or receives. An RF trace records radio signals in the air; RF means radio frequency. A capture point is the place where the team records that evidence. The two traces expose different faults, so choose the point that can observe the claim under test.

20.2 Route Overview

This section: Route Overview — This is part 2 of 2.

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

20.3 Learning Objectives

This section: 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

This section: 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

This section: Capture Points — The map in Figure 20.1 shows where traffic can be seen; choose a point that answers the question.

The map in Figure 20.1 shows where traffic can be seen; choose a point that answers the question.

+

The device, radio, and gateway points in Figure 20.1 show different traffic; choose the needed view.

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

20.6 Tool Roles

This section: Tool Roles — Do not rank tools in the abstract.

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

Inspect Figure 20.2 and ask whether the proposed tool can see the layer where the fault is suspected.

+

Read Figure 20.2 from the question to the three review paths. TCP/IP faults call for packet dissection, timelines, and stream following at a point that can observe the handshake or retransmission. MQTT topic or payload faults require visibility into the affected fields, while LoRaWAN radio problems call for RF, device, or gateway evidence about joins and link conditions. The final visibility check prevents a category error: choosing a familiar application does not help if the capture point cannot expose the suspected exchange. The diagram therefore turns the tool list above into a selection rule. Start with the layer and observation point, then choose the smallest tool role that can answer the review question.

# 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

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

20.7 Reading a Trace

This section: Reading a Trace — The strongest traffic analysis reports behavior, not just packets.

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

20.8 Encryption and Evidence Limits

This section: Encryption and Evidence Limits — Modern IoT traffic is often encrypted.

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.

20.9 Comparing Traffic With Simulation

This section: Comparing Traffic With Simulation — Traffic analysis is especially useful after simulation because it tests whether modeled assumptions match a field or pilot system.

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

20.10 Incremental Examples

This section: Incremental Examples

20.11 Broker Disconnect Evidence

This section: Broker Disconnect Evidence — A pilot deployment reports that a device sometimes disappears from the dashboard even though firmware logs say the sensor is running.

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

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

This section: Try It Now — 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.

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

This section: Micro-Exercise: Pick the Capture Point — First: A sensor publishes locally, but no alert appears in the dashboard.

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

This section: Practice Checks

20.15 Common Pitfalls

This section: Common Pitfalls

20.16 Summary

This section: Summary — Network traffic analysis validates what a network actually did.

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

This section: References — First: Wireshark User’s Guide - official Wireshark packet-analysis documentation.

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

This section: See Also — First: Network Simulation Methodology: compare field traces with scenario packs, model boundaries, and acceptance bands.

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

This section: What’s Next

20.20 Key Takeaway

This section: Key Takeaway — Traffic analysis turns device behavior into network load.

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 section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Network Traffic Analysis: Evidence Paths or continue from the design-methodology module index.