14 Traffic Analysis Fundamentals
Packets as Evidence, Capture Points, Filters, and Bounded Conclusions
IoT traffic analysis, packet capture, pcap, capture point, capture filter, display filter, promiscuous mode, monitor mode, latency jitter throughput packet loss
14.1 Start Simple: Follow One Missing Message
Picture a temperature sensor that says it sent a reading, while the dashboard never changes. The first move is not to capture everything. The first move is to ask one plain question: did the message leave the device, cross the gateway, and reach the service boundary?
That question gives traffic analysis its shape. You choose the place to watch, keep the packet record, and compare what the wire showed with the device log and service record. If the message is absent at the device, the story is different from a message that leaves the device but never reaches the service. Start there, and every later filter, figure, and knowledge check has a job.
14.2 Packets Are Evidence, Not the Whole Story
Traffic analysis lets you compare what a device claims it did with what the network actually carried. A device log says it published a reading; a packet capture shows whether a packet ever left, where it went, and what the other end did with it. In IoT systems that comparison explains the failures that logs alone cannot: missing messages, unexpected reconnects, wrong protocol state, endless retries, or a quiet disagreement between a device log and a service record.
The discipline that keeps it honest is simple. Start with a review question, choose an observation point that can actually see the path in question, record the capture scope and any filters, examine only the packets that bear on the question, and write down what the capture does not show. A trace is evidence, never a complete explanation by itself, because every capture is taken from one vantage point and a vantage point has blind spots.
If you only need the intuition, this layer is enough: a packet capture answers “did this communication happen, where, and in what order,” not “was the sensor right” or “did the firmware choose correctly.” It surfaces network-quality signals — latency, jitter, throughput, packet loss — and protocol state, but the conclusion you draw must never be broader than the point you captured from.
The One-Minute View
Question first
Start from the behavior that needs packet evidence, not from the capture tool. The question chooses the observation point.
Point has blind spots
A capture only shows what is visible from where it was taken. Name the point, and keep the conclusion within what it can see.
Record the limit
Encryption, filters, and radio mode all hide things. Write down what the trace did not expose before you trust it.
Beginner Examples
- A device log claims a message was sent, but a device-side capture shows no packet ever left — the log and the wire disagree, and the wire wins.
- An app shows stale data; a capture reveals a reconnect storm where the session keeps dropping before the publish completes.
- “The packet is encrypted, so I learned nothing” is wrong — you still see the endpoints, the timing, the retries, and the resets.
Overview Knowledge Check
If you can explain why a trace is evidence rather than an explanation, you have the core idea. Continue to Practitioner for capture points and filters.
14.3 Capture Points, Filters, and What You Can Measure
The same device behavior looks different from the device, the gateway, a mirrored switch port, the access point, or the service. Choosing the observation point is the most consequential decision in a traffic review, because it sets what the capture can and cannot support. Pick the point that can actually observe the disputed path, and if no single point can, capture at more than one and reconcile them.
Capture Filters Versus Display Filters
These solve different problems and a common mistake is to confuse them. A capture filter is applied while packets are being saved; it shrinks the capture to a known scope and is useful when the question is already narrow — but it permanently discards anything it excludes, so a retry, handshake, or reset you did not anticipate is simply gone. A display filter is applied after packets are saved; it narrows what you look at while preserving the full capture for later questions, which is safer when the investigation might change direction. Either way, the filter belongs in the record so another reviewer can repeat the analysis.
Promiscuous Mode and Monitor Mode
A network interface normally ignores frames not addressed to it. Promiscuous mode asks a wired interface to hand all visible Ethernet traffic to the capture tool — but it does not make switched traffic appear, because a switch only forwards frames to the relevant port; that is what port mirroring is for. Wireless review usually needs monitor mode or a dedicated radio capture path, and the record must name the channel, mode, and adapter, because a wireless capture on the wrong channel is silently incomplete.
What the Wire Actually Measures
Beyond “did a packet appear,” a capture yields network-quality signals that matter for IoT: latency (the delay before a response), jitter (the variation in that delay, which breaks time-sensitive flows), throughput (the achieved data rate), and packet loss (missing packets, often visible as retransmissions). These are observable from the trace and are frequently the real story behind “the app feels slow” or “readings arrive late.”
Practitioner Knowledge Check
If you can pick the right capture point, distinguish the two kinds of filter, and read latency, jitter, and loss, you can stop here. Continue to Under the Hood for protocol state and how to bound a conclusion.
14.4 Protocol State and Bounding the Claim
The deeper skill is reading the conversation, not just counting packets, and then refusing to conclude more than the trace can support. Two failures dominate real reviews: reading protocol state incorrectly, and stretching a network observation into a claim about the sensor or the firmware.
Read the Conversation, Reconcile the Records
IoT protocols have observable state on the wire. A TCP connection shows its handshake, retransmissions, and resets; an MQTT session shows CONNECT, SUBSCRIBE, and PUBLISH exchanges; a CoAP exchange shows requests, responses, and retransmissions over UDP. A secured session shows its handshake too — a TLS handshake over TCP, or a DTLS handshake for CoAP over UDP — so you can confirm whether an encrypted session even started before application data was attempted. When a device log, a gateway capture, and a service record disagree, reconcile them before concluding; the log is a claim, the capture is an observation, and the truth is usually found by comparing them on message time, endpoint pair, and sequence.
Encryption Hides Contents, Not Metadata
Encryption protects the payload, not the envelope. Even when you cannot read application data, the capture still exposes the endpoints, the timing, the packet sizes, the retransmissions, and the connection resets. That metadata is often enough to localize a problem to the transport or the path — but it is not enough to prove an application-layer cause, and that boundary is exactly where over-conclusion happens.
Bound Every Conclusion
A trace that shows a message moved does not prove the sensor reading was correct. A trace that shows a protocol state does not prove the firmware chose the right state. A service record showing received traffic does not show what happened earlier on the local network. When the question outgrows what the trace can answer, move it to the right layer — a unit or HIL test for firmware logic, a sensor calibration check for measurement validity — rather than forcing the packet evidence to carry a claim it cannot bear.
Common Findings
- Wrong vantage point. The trace was taken where it could not observe the disputed path, so its absence proves nothing.
- Filter hid the answer. A capture filter excluded the very retry or handshake that explained the missing observation.
- Encryption misread. Encrypted payloads were treated as if they exposed application contents.
- Records not reconciled. A log and a trace disagree, but the review never compares them on time, endpoint, and sequence.
- Conclusion too broad. A network observation is stretched into a claim about the sensor or the firmware.
Under-the-Hood Knowledge Check
At this depth, traffic analysis is a discipline of bounded evidence: tie the question to a vantage point, read protocol state honestly, remember that encryption hides contents but not metadata, and reconcile the wire with the logs. A trustworthy review states what the trace shows, what it cannot show, and which layer answers the rest.
14.5 Try It: Inspect a Packet Capture
14.6 Summary
- Traffic analysis compares what a device claims with what the network carried; a packet capture is evidence from one vantage point, not a complete explanation.
- Start from a review question, choose an observation point that can see the disputed path, record the scope and filters, and write down what the trace cannot show.
- Capture points (device, gateway, mirrored switch port, radio, service) each show a different slice; absence at one point is not absence everywhere.
- Capture filters discard excluded packets permanently while saving; display filters narrow the view after capture while preserving the full record. Record whichever is used.
- Promiscuous mode passes visible Ethernet traffic to the tool but does not reveal switched traffic; wireless review needs monitor mode with a recorded channel, mode, and adapter.
- The wire measures latency, jitter, throughput, and packet loss, which are often the real story behind slow or late behavior.
- Protocol state is observable: TCP, MQTT, and CoAP exchanges, and TLS or DTLS handshakes, show whether a session even started before application data.
- Encryption hides contents, not metadata; bound every conclusion and move firmware-logic or sensor-validity questions to the right testing layer.
A packet capture answers where and in what order communication happened, never whether the sensor was right or the firmware was correct. Choose the observation point for the question you are asking, separate capture filters from display filters, read protocol state and network-quality signals honestly, and state the blind spots. The strongest traffic review is the one whose conclusion never exceeds what the chosen vantage point could actually see.
14.7 See Also
Analyzing IoT Protocols
Apply this method to MQTT, CoAP, and other protocol conversations as packet evidence.
Traffic Capture Tools
Select and operate capture utilities once the review question and observation point are clear.
Traffic Analysis in Testing
Fold packet evidence into a repeatable test and monitoring workflow.
Network Simulation Tools
Contrast observed traffic with model-based network evidence from simulation.