16 Traffic Capture Tools

16.1 Learning Objectives

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

Operate Wireshark for graphical network traffic analysis with deep protocol inspection
Apply tcpdump for lightweight command-line packet capture on headless systems
Leverage tshark for scriptable traffic analysis and automation
Select appropriate specialized sniffers for Zigbee, LoRa, and Bluetooth LE protocols
Configure remote capture from IoT gateways and embedded devices

In 60 Seconds

Traffic capture tools for IoT include: Wireshark (GUI packet analyzer with dissectors for MQTT, CoAP, AMQP, BLE, Zigbee), tshark (CLI Wireshark for scripted capture), tcpdump (lightweight command-line capture), and protocol-specific tools (MQTT Explorer, Node-RED debug). Hardware sniffers (Ubertooth for BLE, Zigbee sniffer dongles) capture wireless protocols that cannot be captured by software-only means. Each tool has specific strengths for different IoT traffic analysis scenarios.

16.2 For Beginners: Traffic Capture Tools

Testing and validation ensure your IoT device works correctly and reliably in the real world, not just on your workbench. Think of it like test-driving a car in rain, snow, and heavy traffic before buying it. Thorough testing catches problems before your devices are deployed to thousands of locations where fixing them becomes expensive and disruptive.

Sensor Squad: The Detective’s Toolkit

“Every network detective needs the right tools!” said Max the Microcontroller, opening a toolbox. “Wireshark is tool number one – a graphical packet analyzer that shows every detail of network traffic in a friendly interface. It is the gold standard for protocol analysis.”

Sammy the Sensor described the command-line option. “tcpdump runs on headless Linux devices – perfect for IoT gateways and Raspberry Pis that do not have a screen. You SSH into the gateway, run tcpdump to capture packets, then transfer the file to your laptop to analyze in Wireshark.” Lila the LED added, “tshark is Wireshark’s command-line sibling. It can filter, parse, and export packet data in scripts. Perfect for automated analysis – write a script that captures 1,000 MQTT packets, counts errors, and sends you a report.”

Bella the Battery mentioned specialized sniffers. “For wireless protocols like Zigbee and Bluetooth LE, you need special hardware sniffers. A TI CC2531 USB dongle captures Zigbee traffic. A Nordic nRF52840 dongle captures BLE advertisements. And a HackRF or RTL-SDR can capture LoRa signals for analysis. Each protocol has its own sniffer, but they all feed into Wireshark for analysis.”

16.3 Prerequisites

Before diving into this chapter, you should be familiar with:

Traffic Analysis Fundamentals: Understanding capture points, promiscuous mode, and filter types
Networking Basics: TCP/UDP fundamentals, IP addressing, and port numbers

16.4 Video Resources

Video: tcpdump and Command-Line Traffic Analysis

Master command-line packet capture for headless IoT gateways and embedded Linux devices.

Key Commands:

# Capture MQTT traffic on port 1883
tcpdump -i any -n port 1883 -w mqtt_capture.pcap

# Monitor DNS queries from IoT devices
tcpdump -i eth0 -n port 53

# Capture only SYN packets (connection attempts)
tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'

# Real-time display of HTTP requests
tcpdump -i wlan0 -A -s 0 'tcp port 80'

Advanced Topics:

Berkeley Packet Filter (BPF) syntax for precise filtering
Analyzing captures offline with tshark
Automated anomaly detection with scripting
Integration with monitoring platforms (Prometheus, Grafana)

Resources:

Interactive: Packet Capture Analyzer

Interactive: Packet Analysis: Protocol Layers and Filtering

16.5 How It Works: Packet Capture Tool Architecture

Traffic capture tools operate at different layers of the networking stack, each with specific capabilities and trade-offs:

Wireshark Architecture:

libpcap/WinPcap: Low-level packet capture library interfacing with OS kernel
Dissector Framework: Modular protocol parsers (500+ protocols) written in C
Qt GUI: Cross-platform graphical interface for packet display and filtering
Capture Engine: Buffers packets in memory, writes to disk in pcap/pcapng format
Analysis Tools: Statistics, graphs, expert systems for automated problem detection

tcpdump Architecture:

BPF (Berkeley Packet Filter): Kernel-level filtering executed at packet capture (before user-space copy)
Minimal Overhead: No GUI, direct-to-file writing reduces CPU/memory usage
SSH-Friendly: Text-based output works over remote connections with minimal bandwidth
Scriptable: Shell scripts can automate capture start/stop, rotation, analysis

tshark Architecture:

Uses Wireshark’s dissector library (same protocol parsing)
Command-line interface for scriptable workflows
Can export to CSV, JSON, XML for integration with analysis tools
Combines tcpdump’s low overhead with Wireshark’s protocol intelligence

Putting Numbers to It

Capture Tool CPU Overhead: Gateway with 300MHz ARM CPU (1 core = 1000ms/sec) capturing 100 packets/second:

tcpdump overhead: \[\text{CPU usage} = \frac{100 \text{ pkt/s} \times 0.08 \text{ ms/pkt}}{1000 \text{ ms/s}} = \frac{8 \text{ ms/s}}{1000 \text{ ms/s}} = 0.8\%\]

tshark with dissectors overhead: \[\text{CPU usage} = \frac{100 \text{ pkt/s} \times 0.45 \text{ ms/pkt}}{1000 \text{ ms/s}} = \frac{45 \text{ ms/s}}{1000 \text{ ms/s}} = 4.5\%\]

Wireshark GUI (X11 forwarded over SSH, 200ms latency): \[\text{CPU usage} = 15\% \text{ (GUI rendering)} + 4.5\% \text{ (dissection)} + 8\% \text{ (X11 overhead)} = 27.5\%\]

For 24-hour capture on gateway:

tcpdump: 0.8% CPU, no remote lag
tshark: 4.5% CPU, usable remotely
Wireshark: 27.5% CPU + unusable GUI lag

Best practice: Capture with tcpdump on gateway (minimal overhead), copy pcap file to workstation, analyze with Wireshark offline. For live debugging, tshark provides protocol detail without GUI overhead.

Interactive Calculator: Capture Tool CPU Overhead

Show code

viewof packetsPerSec = Inputs.range([10, 500], {
  value: 100,
  step: 10,
  label: "Packets per second:"
})

viewof cpuFreqMHz = Inputs.range([100, 1000], {
  value: 300,
  step: 50,
  label: "CPU frequency (MHz):"
})

// Processing time per packet (ms)
tcpdumpTime = 0.08
tsharkTime = 0.45
wiresharkGUI = 15
wiresharkDissection = 4.5
wiresharkX11 = 8

// Calculate CPU usage percentages
tcpdumpCPU = (packetsPerSec * tcpdumpTime / 1000) * 100
tsharkCPU = (packetsPerSec * tsharkTime / 1000) * 100
wiresharkCPU = wiresharkGUI + wiresharkDissection + wiresharkX11

// Format results
html`
<div style="margin: 20px 0; padding: 20px; background: #f8f9fa; border-radius: 8px; font-family: -apple-system, sans-serif;">
  <h4 style="margin-top: 0; color: #2C3E50;">CPU Overhead at ${packetsPerSec} pkt/s on ${cpuFreqMHz}MHz ARM CPU</h4>

  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 15px; margin-top: 15px;">

    <div style="padding: 15px; background: white; border-left: 4px solid #16A085; border-radius: 4px;">
      <div style="font-size: 0.85em; color: #7F8C8D; font-weight: 600;">TCPDUMP</div>
      <div style="font-size: 1.8em; font-weight: bold; color: #16A085; margin: 5px 0;">${tcpdumpCPU.toFixed(2)}%</div>
      <div style="font-size: 0.8em; color: #7F8C8D;">Minimal overhead, ideal for embedded</div>
    </div>

    <div style="padding: 15px; background: white; border-left: 4px solid #3498DB; border-radius: 4px;">
      <div style="font-size: 0.85em; color: #7F8C8D; font-weight: 600;">TSHARK</div>
      <div style="font-size: 1.8em; font-weight: bold; color: #3498DB; margin: 5px 0;">${tsharkCPU.toFixed(2)}%</div>
      <div style="font-size: 0.8em; color: #7F8C8D;">Protocol analysis, scriptable</div>
    </div>

    <div style="padding: 15px; background: white; border-left: 4px solid #E67E22; border-radius: 4px;">
      <div style="font-size: 0.85em; color: #7F8C8D; font-weight: 600;">WIRESHARK (GUI)</div>
      <div style="font-size: 1.8em; font-weight: bold; color: #E67E22; margin: 5px 0;">${wiresharkCPU.toFixed(1)}%</div>
      <div style="font-size: 0.8em; color: #7F8C8D;">High overhead, not for remote use</div>
    </div>

  </div>

  <div style="margin-top: 20px; padding: 15px; background: white; border-radius: 4px; border: 1px solid #e0e0e0;">
    <h5 style="margin: 0 0 10px 0; color: #2C3E50;">Calculation Details</h5>
    <div style="font-size: 0.9em; color: #555; line-height: 1.6;">
      <div><strong>tcpdump:</strong> (${packetsPerSec} pkt/s × ${tcpdumpTime} ms/pkt) / 1000 ms/s = ${(packetsPerSec * tcpdumpTime / 10).toFixed(2)} ms/s = ${tcpdumpCPU.toFixed(2)}%</div>
      <div><strong>tshark:</strong> (${packetsPerSec} pkt/s × ${tsharkTime} ms/pkt) / 1000 ms/s = ${(packetsPerSec * tsharkTime / 10).toFixed(2)} ms/s = ${tsharkCPU.toFixed(2)}%</div>
      <div><strong>Wireshark:</strong> ${wiresharkGUI}% (GUI) + ${wiresharkDissection}% (dissection) + ${wiresharkX11}% (X11) = ${wiresharkCPU}%</div>
    </div>
  </div>

  <div style="margin-top: 15px; padding: 12px; background: ${tcpdumpCPU > 5 ? '#fff3cd' : '#d4edda'}; border-radius: 4px; border-left: 4px solid ${tcpdumpCPU > 5 ? '#E67E22' : '#16A085'};">
    <div style="font-size: 0.9em; color: #2C3E50;">
      <strong>Recommendation:</strong> ${
        tcpdumpCPU < 2 ?
          "tcpdump has minimal impact - safe for continuous capture on this gateway." :
        tcpdumpCPU < 5 ?
          "tcpdump is manageable, but monitor CPU if running other services." :
        tcpdumpCPU < 10 ?
          "Consider reducing packet rate or using capture filters to reduce CPU load." :
          "High CPU load! Use capture filters (port 1883) to reduce processed packets."
      }
    </div>
  </div>

</div>
`

Key Insight: On constrained IoT gateways, tcpdump uses 5-20× less CPU than tshark, and 20-40× less than Wireshark GUI. For production deployments, always capture with tcpdump locally and analyze offline with Wireshark on a workstation.

Why This Design: tcpdump captures efficiently on constrained devices (IoT gateways, embedded Linux). Wireshark analyzes rich protocol details on powerful workstations. tshark bridges both worlds for automation.

16.6 Traffic Capture Tools

~25 min | Intermediate | P13.C06.U02

16.6.1 Wireshark

Description: Industry-standard graphical network protocol analyzer with extensive protocol support.

Key Features:

Deep packet inspection for hundreds of protocols
Graphical interface with intuitive filtering
Protocol dissectors for IoT protocols (MQTT, CoAP, Zigbee)
Statistical analysis and graphing
Conversation tracking and flow analysis
Export capabilities (CSV, JSON, etc.)

Installing Wireshark:

Ubuntu/Debian:

sudo apt update
sudo apt install wireshark
sudo usermod -a -G wireshark $USER  # Allow non-root capture

macOS:

brew install --cask wireshark

Basic Workflow:

Start Capture:
- Select interface (eth0, wlan0, etc.)
- Optional: Apply capture filter
- Click “Start”
Observe Traffic:
- Real-time packet list view
- Select packet to see details
- Examine packet bytes in hex view
Apply Display Filters:
- Filter for specific protocols, hosts, or patterns
- Right-click fields to create filters quickly
Analyze:
- Statistics -> Protocol Hierarchy (traffic breakdown)
- Statistics -> Conversations (device communication pairs)
- Statistics -> I/O Graph (traffic over time)
Save:
- File -> Save As (pcap format for later analysis)

Example: Analyzing MQTT Traffic

Display filter: mqtt

Look for: - CONNECT: Client connecting to broker - CONNACK: Broker accepting connection - SUBSCRIBE: Client subscribing to topics - PUBLISH: Message publication - PUBACK: QoS 1 acknowledgment - DISCONNECT: Clean disconnection

Common issues to identify: - Repeated CONNECT attempts (connection failing) - Missing PUBACK (message delivery failures) - Unusual PUBLISH frequency (device malfunction)

16.6.2 tcpdump

Description: Command-line packet capture tool, lightweight and available on most Unix-like systems.

Key Features:

Minimal resource usage (suitable for embedded devices)
Powerful capture filter syntax (BPF)
Can run on headless systems
Output to pcap files for later Wireshark analysis
Remote capture over SSH

Basic Usage:

Capture all traffic:

sudo tcpdump -i eth0

Capture to file:

sudo tcpdump -i eth0 -w capture.pcap

Capture specific port with timestamp and packet count:

sudo tcpdump -i eth0 -n -ttttt -c 100 port 1883

Capture with detailed output:

sudo tcpdump -i eth0 -v -X  # -v verbose, -X hex+ASCII

Filter examples:

# MQTT traffic
sudo tcpdump -i eth0 port 1883 or port 8883

# CoAP traffic
sudo tcpdump -i eth0 port 5683 or port 5684

# Specific device
sudo tcpdump -i eth0 host 192.168.1.50

# HTTP traffic from IoT device
sudo tcpdump -i eth0 'src 192.168.1.50 and tcp port 80'

Remote Capture: Capture from remote device and analyze locally in Wireshark:

ssh user@iot-gateway "sudo tcpdump -i eth0 -U -w -" | wireshark -k -i -

16.6.3 tshark

Description: Terminal version of Wireshark, combining tcpdump’s CLI with Wireshark’s protocol dissection.

Key Features:

Wireshark’s protocol analyzers in command-line form
Scriptable for automation
Can export to multiple formats
Suitable for remote/headless analysis

Basic Usage:

Capture and display:

sudo tshark -i eth0

Capture with specific fields:

sudo tshark -i eth0 -T fields -e frame.time -e ip.src -e ip.dst -e mqtt.topic

Read from pcap file:

tshark -r capture.pcap

Filter and statistics:

# Count MQTT packets by topic
tshark -r capture.pcap -Y mqtt -T fields -e mqtt.topic | sort | uniq -c

# Average packet size
tshark -r capture.pcap -q -z io,stat,0,AVG(frame.len)

# Protocol hierarchy
tshark -r capture.pcap -q -z io,phs

Automated Analysis Script Example:

#!/bin/bash
# Analyze MQTT traffic from capture file

CAPTURE=$1

echo "=== MQTT Traffic Analysis ==="
echo ""

echo "Total MQTT packets:"
tshark -r $CAPTURE -Y mqtt | wc -l

echo ""
echo "MQTT message types:"
tshark -r $CAPTURE -Y mqtt -T fields -e mqtt.msgtype | sort | uniq -c

echo ""
echo "Published topics:"
tshark -r $CAPTURE -Y "mqtt.msgtype == 3" -T fields -e mqtt.topic | sort | uniq -c

echo ""
echo "Subscribed topics:"
tshark -r $CAPTURE -Y "mqtt.msgtype == 8" -T fields -e mqtt.topic | sort | uniq -c

Mind map diagram centered on Network Analysis Tools with five main branches: Packet Capture branch includes Wireshark GUI for graphical packet analysis, tcpdump CLI for command-line capture, TShark automation for scriptable analysis, and ngrep for pattern matching. Protocol Analyzers branch contains MQTT Explorer for message broker debugging, CoAP client for CoAP protocol testing, Bluetooth sniffer for BLE traffic, and Zigbee analyzer for mesh network analysis. Hardware Sniffers branch lists Nordic nRF Sniffer for Bluetooth/Zigbee capture, Ubertooth BLE for low-level Bluetooth, CC2531 Zigbee USB dongle, and Wi-Fi monitor mode for wireless capture. Cloud Platforms branch shows AWS IoT monitoring, Azure IoT analytics, and ThingsBoard debug for cloud-integrated analysis. Custom Tools branch includes Python scapy for packet crafting, Node.js MQTT spy for MQTT debugging, and Custom dissectors for proprietary protocols. Comprehensive ecosystem covers software tools, hardware sniffers, cloud integration, and extensibility for IoT network analysis across all protocol layers and deployment environments.

16.6.4 Specialized IoT Capture Tools

Zigbee/Thread Sniffers:

Texas Instruments CC2531 USB Sniffer
Nordic nRF52840 dongle
Atmel RZRaven USB Stick

Use with Wireshark for Zigbee protocol analysis.

LoRa Sniffers:

LoRa gateway in promiscuous mode
SDR (Software Defined Radio) with GNU Radio
Commercial LoRa sniffers

Bluetooth LE Sniffers:

Nordic nRF52840 DK
Ubertooth One
Adafruit Bluefruit LE Sniffer
Built-in on some Android devices (HCI snoop log)

16.7 Worked Example: Debugging Intermittent MQTT Disconnections

Scenario: A building management company deploys 50 ESP32 sensors monitoring temperature and humidity via MQTT (QoS 1) to a Mosquitto broker on a Raspberry Pi gateway. After 2 weeks, 8-12 sensors drop offline every night between 2-4 AM, then reconnect at dawn. The firmware team suspects a bug, but the issue never occurs during daytime testing.

Step 1: Remote Capture Setup

The gateway is in a locked server closet. Set up remote tcpdump capture piped to a local Wireshark instance:

# On workstation: stream gateway traffic to Wireshark
ssh admin@192.168.1.1 "sudo tcpdump -i eth0 -U -w - port 1883" | \
  wireshark -k -i -

Leave running overnight. Result: 847 MB pcap file covering 00:00-06:00.

Step 2: Filter for Disconnection Events

In Wireshark, filter for MQTT DISCONNECT and TCP RST packets:

mqtt.msgtype == 14 || tcp.flags.reset == 1

Findings:

Time	Event	Source IP	Details
02:14:33	TCP RST	192.168.1.35	RST from gateway to sensor
02:14:33	TCP RST	192.168.1.38	Same second
02:14:34	TCP RST	192.168.1.41	+1 second
…	…	…	8 more RSTs in 3 seconds
02:14:37	MQTT CONNECT	192.168.1.35	Sensor reconnecting

All disconnections cluster within a 3-second window. This rules out individual sensor bugs – something on the gateway is killing connections simultaneously.

Step 3: Correlate with Gateway Activity

Use tshark to analyze what the gateway was doing at 02:14:

tshark -r overnight.pcap -Y "frame.time >= \"02:14:30\" && \
  frame.time <= \"02:14:40\"" -T fields \
  -e frame.time -e ip.src -e ip.dst -e tcp.len -e mqtt.msgtype \
  | head -30

Discovery: At 02:14:32, a burst of 200+ MQTT PUBLISH messages arrive from the broker’s retained message replay – a nightly backup script restarts Mosquitto, which replays all retained messages simultaneously. The Raspberry Pi’s 1 GB RAM fills, the kernel OOM-killer terminates Mosquitto, and all TCP connections receive RST.

Step 4: Verify Root Cause

# Check gateway system logs for OOM events
ssh admin@192.168.1.1 "journalctl -u mosquitto --since '02:14:00' \
  --until '02:15:00'"

Output confirms: Out of memory: Killed process 1234 (mosquitto).

Solution: Move the backup script from 2 AM to a mosquitto_pub command that saves retained messages without restarting the broker. Alternatively, increase the Pi’s swap space or upgrade to 4 GB model.

Lesson: Intermittent IoT failures often correlate with scheduled system tasks (backups, log rotation, certificate renewal). Traffic capture timestamps are the key to correlating network events with system events.

16.8 Common Pitfalls

Tool Selection Mistakes

1. Using Wireshark on Production Systems

Mistake: Running Wireshark with full packet capture on a production gateway, causing CPU overload and dropped packets
Why it happens: Wireshark’s GUI and real-time analysis consume significant resources
Solution: Use tcpdump for lightweight capture on production systems, then transfer pcap files for Wireshark analysis offline

2. Forgetting Remote Capture Options

Mistake: Physically connecting a laptop to debug an IoT gateway in a remote location
Why it happens: Not realizing tcpdump can stream directly to Wireshark over SSH
Solution: Use ssh user@device "tcpdump -w -" | wireshark -k -i - for real-time remote analysis

3. Missing Wireless Protocol Hardware

Mistake: Trying to capture Zigbee traffic with standard network tools and seeing nothing
Why it happens: Zigbee, BLE, and LoRa operate on different radio frequencies requiring specialized hardware
Solution: Budget $50-300 for appropriate sniffers (CC2531 for Zigbee, nRF52840 for BLE, SDR for LoRa)

16.9 Concept Relationships

How This Concept Connects

Prerequisites:

Traffic Analysis Fundamentals: Capture points, promiscuous mode, filter types
Networking Basics: TCP/UDP, IP addressing, ports

Build On This:

Analyzing IoT Protocols: Protocol-specific analysis with these tools
Traffic Analysis Testing: Automated testing with tshark

Real-World Application:

Integration Testing: Using traffic capture to validate protocol behavior
Security Testing: Packet analysis for vulnerability assessment

16.10 See Also

Further Exploration

Tool Documentation:

Wireshark User Guide - Official documentation
tcpdump Manual - Command reference
tshark Reference - CLI analysis

Related Chapters:

Traffic Analysis Fundamentals: Core concepts
Analyzing IoT Protocols: Protocol-specific techniques

16.11 Try It Yourself: Remote Packet Capture

Hands-On Exercise

Objective: Capture traffic from a remote IoT gateway and analyze locally in Wireshark.

What You’ll Need:

Remote Linux device (Raspberry Pi, IoT gateway) with tcpdump
SSH access to remote device
Wireshark on local machine

Exercise:

# Stream remote capture directly to local Wireshark
ssh user@iot-gateway "sudo tcpdump -i eth0 -U -w - port 1883" | wireshark -k -i -

# Alternative: Save remotely, transfer, analyze offline
ssh user@iot-gateway "sudo tcpdump -i eth0 -w /tmp/mqtt.pcap -c 1000 port 1883"
scp user@iot-gateway:/tmp/mqtt.pcap ./
wireshark mqtt.pcap

What to Observe:

Real-time packet analysis without X11 forwarding
-U flag ensures packets stream immediately (unbuffered)
-w - writes to stdout for pipe to Wireshark
Useful for devices in locked server rooms or remote locations

Challenge: Modify to capture from multiple gateways simultaneously using multiple SSH sessions.

Matching Exercise: Key Concepts

Order the Steps

Label the Diagram

💻 Code Challenge

🧠 Knowledge Check

16.12 Summary

Wireshark provides comprehensive graphical analysis with protocol dissectors for MQTT, CoAP, Zigbee, and hundreds of other protocols
tcpdump offers lightweight command-line capture ideal for embedded devices and remote gateways
tshark combines Wireshark’s protocol analysis with scriptable CLI operation for automation
Specialized hardware sniffers are required for wireless protocols like Zigbee (CC2531), BLE (nRF52840), and LoRa (SDR)
Remote capture via SSH enables analysis of traffic from headless IoT devices using local tools

16.13 What’s Next

Continue to Analyzing IoT Protocols to learn protocol-specific analysis techniques for MQTT, CoAP, Zigbee, and LoRaWAN traffic.

Previous	Current	Next
Traffic Analysis Fundamentals	Traffic Capture Tools	Analyzing IoT Protocols