1566  Packet Analysis: IoT Protocol Scenarios

1566.1 Learning Objectives

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

  • Analyze MQTT sessions: Identify connection, subscription, and publish patterns
  • Interpret CoAP exchanges: Understand confirmable messages and retransmissions
  • Read BLE discovery sequences: Trace advertising, scanning, and connection establishment
  • Understand Zigbee joining: Follow network association and device announcement
  • Detect anomalies: Recognize retransmissions, failures, and error patterns

1566.2 Introduction

Real-world IoT packet analysis involves understanding protocol-specific behaviors. This chapter walks through common scenarios for MQTT, CoAP, BLE, and Zigbee, explaining what to look for and how to interpret the captured traffic.

1566.3 MQTT Session Analysis

A typical MQTT session follows a predictable sequence of control packets. Understanding this sequence helps diagnose connection issues and verify correct operation.

1566.3.1 MQTT Session Lifecycle

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
sequenceDiagram
    participant C as Client
    participant B as Broker

    C->>B: CONNECT (Client ID, Clean Session)
    B->>C: CONNACK (Return Code: 0)

    C->>B: SUBSCRIBE (Topic Filter, QoS)
    B->>C: SUBACK (Granted QoS)

    C->>B: PUBLISH (Topic, Payload, QoS 1)
    B->>C: PUBACK (Packet ID)

    B->>C: PUBLISH (Subscribed Message)
    C->>B: PUBACK (Packet ID)

    C->>B: PINGREQ
    B->>C: PINGRESP

    C->>B: DISCONNECT

1566.3.2 MQTT Control Packets

Packet Type Code Direction Purpose
CONNECT 1 Client to Broker Establish session
CONNACK 2 Broker to Client Acknowledge connection
PUBLISH 3 Bidirectional Send message
PUBACK 4 Bidirectional QoS 1 acknowledgment
SUBSCRIBE 8 Client to Broker Request topic subscription
SUBACK 9 Broker to Client Confirm subscription
PINGREQ 12 Client to Broker Keep-alive ping
PINGRESP 13 Broker to Client Keep-alive response
DISCONNECT 14 Client to Broker Clean session termination

1566.3.3 What to Look For

Healthy MQTT Session Indicators:

  • CONNECT followed immediately by CONNACK (Return Code 0)
  • SUBSCRIBE followed by SUBACK with granted QoS
  • PUBLISH/PUBACK pairs complete within expected timeouts
  • Regular PINGREQ/PINGRESP at keep-alive intervals
WarningMQTT Anomalies to Watch
  • Repeated CONNECTs: Client struggling to maintain connection
  • CONNACK Return Code != 0: Authentication failure or protocol error
  • Missing PUBACKs: Message delivery failures
  • High PINGREQ frequency: Aggressive keep-alive settings
  • DISCONNECT without prior notice: Network interruption
  • Duplicate packet IDs: Client or broker confusion

1566.3.4 Example: Diagnosing Connection Issues

If you see this pattern:

1. CONNECT (sensor-001)
2. CONNACK (Return Code: 5)
3. [TCP FIN]

Return Code 5 means “Not Authorized” - check client credentials.

1566.4 CoAP Exchange Analysis

CoAP uses a simpler message model than MQTT, with explicit handling of unreliable networks through confirmable messages.

1566.4.1 CoAP Message Types

Type Code Reliability Use Case
CON 0 Confirmable Critical data requiring ACK
NON 1 Non-confirmable Best-effort telemetry
ACK 2 Acknowledgment Response to CON
RST 3 Reset Error indication

1566.4.2 CoAP Retransmission Pattern

CoAP uses exponential backoff for confirmable messages:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
gantt
    title CoAP Retransmission Timeline
    dateFormat X
    axisFormat %s

    section Client
    CON GET /temp (MID:0x1234)    :a1, 0, 1
    Retransmit 1 (T+2s)          :a2, 2000, 1
    Retransmit 2 (T+6s)          :a3, 6000, 1
    Retransmit 3 (T+14s)         :a4, 14000, 1

    section Server
    ACK 2.05 Content             :b1, 6500, 1

Retransmission Schedule:

  • Initial transmission at T+0
  • Retransmission 1 at T+2s (if no ACK)
  • Retransmission 2 at T+6s
  • Retransmission 3 at T+14s
  • After 4 attempts: Message considered lost

1566.4.3 CoAP Response Codes

CoAP uses HTTP-like response codes:

Code Class Meaning
2.01 Success Created
2.04 Success Changed
2.05 Success Content
4.00 Client Error Bad Request
4.04 Client Error Not Found
5.00 Server Error Internal Error
TipCoAP Troubleshooting Tips
  1. Count retransmissions: More than 1-2 indicates network issues
  2. Check Message IDs: Each CON should have unique MID
  3. Verify tokens: Request/response matching uses tokens
  4. Monitor NON usage: Too many NON messages may indicate lost data

1566.5 BLE Device Discovery

BLE discovery involves advertising, scanning, and connection establishment - all visible in packet captures.

1566.5.1 BLE Discovery Sequence

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
sequenceDiagram
    participant P as Peripheral
    participant C as Central

    loop Advertising (Periodic)
        P->>C: ADV_IND (Device Name, Services)
    end

    C->>P: SCAN_REQ
    P->>C: SCAN_RSP (Extended Data)

    C->>P: CONNECT_IND (Connection Parameters)

    Note over P,C: Connection Established

    C->>P: ATT Exchange MTU Request
    P->>C: ATT Exchange MTU Response

    C->>P: ATT Read By Group Type (Primary Services)
    P->>C: ATT Read By Group Type Response

    C->>P: ATT Read Request (Characteristic)
    P->>C: ATT Read Response (Value)

1566.5.2 BLE PDU Types

PDU Type Direction Purpose
ADV_IND Peripheral broadcast Connectable advertising
ADV_NONCONN_IND Peripheral broadcast Non-connectable advertising (beacons)
SCAN_REQ Central to Peripheral Request scan response
SCAN_RSP Peripheral to Central Provide additional data
CONNECT_IND Central to Peripheral Initiate connection

1566.5.3 Advertising Data Fields

Type Name Example Value
0x01 Flags LE General Discoverable
0x09 Complete Local Name “IoT-Sensor-01”
0x03 Complete 16-bit UUIDs Battery Service (0x180F)
0xFF Manufacturer Data Company ID + Custom Data
0x0A TX Power Level -10 dBm
NoteReading BLE Captures
  1. ADV_IND packets show periodic broadcasts (typically every 20-100ms)
  2. RSSI values indicate signal strength (closer to 0 = stronger)
  3. ATT exchanges reveal service/characteristic discovery
  4. Connection parameters affect power consumption and latency

1566.6 Zigbee Network Joining

Zigbee network association involves multiple protocol layers - MAC, NWK, APS, and ZCL.

1566.6.1 Zigbee Join Sequence

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
sequenceDiagram
    participant D as Device
    participant C as Coordinator

    D->>C: MAC Beacon Request (Broadcast)
    C->>D: MAC Beacon (PAN ID, Permit Joining)

    D->>C: MAC Association Request
    C->>D: MAC Association Response (Short Address)

    Note over D,C: Device Joined Network

    D->>C: ZDP Device Announce
    D->>C: ZCL Report Attributes (Sensor Data)
    C->>D: ZCL Default Response (Success)

1566.6.2 Zigbee Frame Types

Layer Frame Type Purpose
MAC Beacon Request Scan for networks
MAC Beacon Network advertisement
MAC Association Request/Response Join network
NWK Data Route layer data
APS Data Application data transport
ZDP Device Announce Announce presence
ZCL Report Attributes Send sensor data

1566.6.3 ZCL Clusters (Common IoT)

Cluster ID Name Purpose
0x0006 On/Off Switch control
0x0008 Level Control Dimmer control
0x0402 Temperature Measurement Temperature sensing
0x0405 Relative Humidity Humidity sensing
0x0500 IAS Zone Security sensors
WarningZigbee Analysis Challenges
  • Encrypted traffic: ZCL payload may be encrypted (look for Security field)
  • Mesh routing: Packets may traverse multiple hops
  • Short addresses change: Devices may get new addresses after rejoin
  • Multiple PANs: Scan may reveal neighboring networks

1566.7 HTTP REST API Analysis

HTTP is common in IoT for cloud connectivity and device configuration.

1566.7.1 HTTP Request/Response Patterns

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
sequenceDiagram
    participant D as Device
    participant S as Server

    D->>S: GET /api/sensors
    S->>D: 200 OK (JSON array)

    D->>S: POST /api/sensors/1/data (JSON body)
    S->>D: 201 Created (Location header)

    D->>S: PUT /api/sensors/1/config
    S->>D: 200 OK

    D->>S: DELETE /api/sensors/2
    S->>D: 204 No Content

1566.7.2 HTTP Methods for IoT

Method Use Case Expected Response
GET Read sensor data, config 200 OK with body
POST Submit telemetry 201 Created
PUT Update configuration 200 OK
DELETE Remove resource 204 No Content
PATCH Partial update 200 OK

1566.8 Cross-Protocol Comparison

Aspect MQTT CoAP BLE Zigbee HTTP
Transport TCP UDP LL 802.15.4 TCP
Message Pattern Pub/Sub Request/Response Characteristic R/W Cluster Commands Request/Response
Reliability QoS 0/1/2 CON/NON Notifications ACK frames TCP guarantees
Security TLS DTLS Pairing Network Key TLS
Typical Use Telemetry Resource access Wearables Home automation Cloud APIs

1566.9 Summary

ImportantKey Takeaways
  1. MQTT sessions follow predictable patterns: CONNECT, SUBSCRIBE, PUBLISH, DISCONNECT
  2. CoAP retransmissions indicate reliability: Count them to assess network quality
  3. BLE discovery reveals device capabilities: Services, characteristics, RSSI
  4. Zigbee joining involves multiple layers: MAC, NWK, APS, ZCL
  5. Each protocol has characteristic anomalies: Know what to watch for
  6. Cross-protocol captures are common: IoT networks often mix protocols

1566.10 What’s Next