1567 Packet Analysis: Advanced Techniques

1567.1 Learning Objectives

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

Read hex dumps: Interpret raw packet bytes and identify protocol signatures
Recognize byte patterns: Find MQTT, CoAP, HTTP, and Zigbee markers in hex
Interpret packet statistics: Use distribution charts, top talkers, and conversation pairs
Analyze traffic patterns: Identify communication topologies and behaviors
Use timing analysis: Understand packets-over-time visualization

1567.2 Introduction

Advanced packet analysis goes beyond reading protocol fields - it involves understanding raw bytes, recognizing patterns, and using statistical analysis to characterize network behavior. This chapter covers hex dump interpretation and statistical analysis techniques essential for deep protocol troubleshooting.

1567.3 Hex Dump Analysis

Hex dumps show raw packet bytes alongside ASCII interpretation. This view is invaluable when protocol parsers fail or when investigating unknown traffic.

1567.3.1 Reading Hex Dump Format

A typical hex dump line shows:

Offset  Hex Values                                    ASCII
0000  10 12 00 04 4d 51 54 54 04 02 00 3c 00 06 73 65  ....MQTT...<..se
0010  6e 73 6f 72                                      nsor

Component	Description
Offset	Byte position from start (hexadecimal)
Hex Values	16 bytes in hex, space-separated
ASCII	Printable characters (. for non-printable)

1567.3.2 Protocol Signatures

Each protocol has recognizable byte patterns:

1567.3.2.1 MQTT Signatures

Bytes	Meaning	Location
`4d 51 54 54`	“MQTT”	Protocol name in CONNECT
`10`	CONNECT packet type (0x10)	First byte
`20`	CONNACK packet type (0x20)	First byte
`30-3f`	PUBLISH packet type (0x30)	First byte (flags vary)

Example MQTT CONNECT hex:

0000  10 12 00 04 4d 51 54 54 04 02 00 3c 00 06 73 65  ....MQTT...<..se
0010  6e 73 6f 72                                      nsor

10: CONNECT packet type
12: Remaining length (18 bytes)
00 04: Protocol name length (4)
4d 51 54 54: “MQTT”
04: Protocol level (4 = MQTT 3.1.1)
02: Connect flags
00 3c: Keep-alive (60 seconds)
00 06 73 65 6e 73 6f 72: Client ID “sensor”

1567.3.2.2 CoAP Signatures

Pattern	Meaning
`40` first byte	Version 1, CON type
`50` first byte	Version 1, NON type
`60` first byte	Version 1, ACK type
`70` first byte	Version 1, RST type

CoAP header structure:

0000  40 01 12 34 ab cd                                @..4..

40: Version (1), Type (CON), Token Length (0)
01: Code (GET)
12 34: Message ID
ab cd: Token (if present)

1567.3.2.3 HTTP Signatures

Bytes	Meaning
`47 45 54 20`	“GET”
`50 4f 53 54`	“POST”
`48 54 54 50`	“HTTP”
`0d 0a 0d 0a`	End of headers (CRLF CRLF)

1567.3.2.4 Zigbee/802.15.4 Signatures

Pattern	Meaning
Frame type in first byte	0=Beacon, 1=Data, 2=ACK, 3=Command
`ff ff ff ff ff ff ff ff`	Broadcast address

1567.3.3 Hex Dump Practice

Exercise: Identify the Protocol

Given this hex dump, identify the protocol:

0000  50 02 00 05 b1 74 65 6d 70                       P....temp

Answer: This is CoAP (0x50 = Version 1, NON type), with code 0x02 (POST), Message ID 0x0005, token 0xb1, and Uri-Path option “temp”.

1567.4 Protocol Identification by Hex

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
flowchart TD
    A[First Byte] --> B{0x10-0x1f?}
    B -->|Yes| C[MQTT CONNECT]
    B -->|No| D{0x20?}
    D -->|Yes| E[MQTT CONNACK]
    D -->|No| F{0x30-0x3f?}
    F -->|Yes| G[MQTT PUBLISH]
    F -->|No| H{0x40-0x7f?}
    H -->|Yes| I[CoAP Message]
    H -->|No| J{0x47/0x50/0x48?}
    J -->|Yes| K[HTTP Method/Response]
    J -->|No| L[Check Link Layer]

    style C fill:#9B59B6,color:#FFFFFF
    style E fill:#9B59B6,color:#FFFFFF
    style G fill:#9B59B6,color:#FFFFFF
    style I fill:#16A085,color:#FFFFFF
    style K fill:#3498DB,color:#FFFFFF

1567.5 Statistics Interpretation

Packet statistics reveal traffic patterns invisible in individual packet analysis.

1567.5.1 Protocol Distribution

Protocol distribution shows which protocols dominate your capture:

Distribution Pattern	Interpretation
High MQTT percentage (>60%)	Active pub/sub telemetry system
High CoAP percentage (>60%)	Resource-constrained device network
Balanced MQTT/HTTP	Hybrid system (sensors + cloud APIs)
Many TCP retransmissions	Network congestion or packet loss

Reading Protocol Distribution

Single protocol dominant: Homogeneous IoT deployment
Multiple protocols balanced: Heterogeneous smart home/building
High TCP/UDP without app layer: Possible scanning or failed connections

1567.5.2 Top Talkers Analysis

Top talkers show which addresses generate the most traffic:

Pattern	Interpretation
One dominant address	Central gateway/broker
Even distribution	Peer-to-peer mesh network
Many sources, one destination	Star topology (sensors to gateway)
Asymmetric traffic	One-way telemetry (more TX than RX)

Example top talkers analysis:

Address           Packets   Percentage
192.168.1.1       150       45%        <- Broker/Gateway
192.168.1.100     80        24%        <- Active sensor
192.168.1.101     55        17%        <- Moderate sensor
192.168.1.102     45        14%        <- Low-activity sensor

Interpretation: Star topology with central broker (192.168.1.1) handling most traffic. Device at .100 is most active sensor.

1567.5.3 Conversation Pairs

Conversation pairs show communication relationships:

Pattern	Topology
Many devices talk to one	Star (sensors to gateway)
Devices talk to neighbors	Mesh (routing through peers)
Full mesh connections	Peer-to-peer application
Hub-spoke with exceptions	Gateway with direct device links

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
flowchart TB
    subgraph Star["Star Topology"]
        G1[Gateway]
        S1[Sensor 1] --> G1
        S2[Sensor 2] --> G1
        S3[Sensor 3] --> G1
    end

    subgraph Mesh["Mesh Topology"]
        M1[Node A]
        M2[Node B]
        M3[Node C]
        M1 <--> M2
        M2 <--> M3
        M1 <--> M3
    end

    style G1 fill:#2C3E50,color:#FFFFFF
    style M1 fill:#16A085,color:#FFFFFF
    style M2 fill:#16A085,color:#FFFFFF
    style M3 fill:#16A085,color:#FFFFFF

1567.5.4 Packets Over Time

Time-based analysis reveals:

Pattern	Interpretation
Periodic bursts	Scheduled sensor reporting
Continuous traffic	Real-time streaming
Sudden spikes	Event-triggered data
Declining traffic	Devices going offline or battery depletion
Regular gaps	Duty cycling or sleep modes

Example patterns:

Time (s)   0   10   20   30   40   50   60
Packets    |   ||   |    ||   |    ||   |
           ^---^    ^----^    ^----^
           30s periodic reporting

1567.6 Timing Analysis

Packet timing reveals network health and protocol behavior.

1567.6.1 Inter-Packet Timing

Measurement	Normal Range	Concern
Request-Response	1-100ms	>500ms indicates latency
Keep-alive interval	30-120s	Missing keep-alives = disconnect
Retransmission delay	2-14s (CoAP)	Multiple retransmits = packet loss
Advertising interval	20-1000ms (BLE)	Affects discovery time

1567.6.2 Delta Time Analysis

Compare expected vs. actual timing:

Expected MQTT keep-alive: 60s
Observed PINGREQ intervals:
  - 60.2s (normal)
  - 59.8s (normal)
  - 75.3s (delayed - network issue?)
  - 60.1s (normal)

Timing Red Flags

Decreasing inter-packet time: Possible retry storm
Large gaps: Network outage or device sleep
Jittery timing: Network congestion or processing delays
Missing responses: Packet loss or server overload

1567.7 Combining Analysis Techniques

Effective troubleshooting combines multiple techniques:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085'}}}%%
flowchart LR
    A[Problem Report] --> B[Filter by Device]
    B --> C[Check Statistics]
    C --> D{Anomalies?}
    D -->|High Retransmits| E[Timing Analysis]
    D -->|Unknown Traffic| F[Hex Dump Review]
    D -->|Protocol Errors| G[Sequence Analysis]
    E --> H[Network Issue]
    F --> I[Identify Protocol]
    G --> J[Application Bug]

    style A fill:#E74C3C,color:#FFFFFF
    style H fill:#27AE60,color:#FFFFFF
    style I fill:#27AE60,color:#FFFFFF
    style J fill:#27AE60,color:#FFFFFF

1567.7.1 Case Study: Intermittent Sensor Failures

Symptoms: Sensor data occasionally missing

Analysis Steps:

Filter by sensor IP: Isolate traffic to/from failing device
Check protocol distribution: Normal MQTT ratio
Examine top talkers: Sensor traffic below expected
Review timing: Large gaps during failures
Hex dump: Valid MQTT frames when present
Conclusion: Likely radio interference or power issues, not protocol problem

1567.8 Summary

Key Takeaways

Hex dumps reveal raw protocol data: Useful when parsers fail
Protocol signatures are identifiable: MQTT (0x10-0x3f), CoAP (0x40-0x7f), HTTP (GET/POST/HTTP)
Statistics show network patterns: Distribution, top talkers, conversation pairs
Timing analysis reveals health: Inter-packet delays, retransmission patterns
Combine techniques for troubleshooting: Filter, statistics, timing, then hex dump
Know normal patterns: Required to identify anomalies

1567.9 What’s Next

Interactive Packet Capture Analyzer - Practice with the interactive tool
Network Conditions Emulator - Test protocol behavior under stress
MQTT Message Flow - Visualize MQTT patterns