Listen to this Post
Introduction:
Network packet analysis is the bedrock of cybersecurity incident response, yet one of the most fundamental skills—determining the true sequence of events across multiple capture points—remains widely misunderstood. When analysts collect packet captures from different locations in a network, each device operates on its own clock, with its own offset, drift, and start time. The seemingly innocent “Time” column in Wireshark can become a treacherous trap, leading investigators to misorder events, misattribute blame, and ultimately miss the root cause of security incidents. This article dismantles the myths around timestamp reliability and equips you with a rigorous, evidence-based methodology for multi-point packet analysis that separates fact from fiction.
Learning Objectives:
- Understand why absolute timestamps across multiple capture points are inherently unreliable and how clock drift, offset, and NTP inconsistencies distort event ordering.
- Master the TCP protocol mechanics—sequence numbers, acknowledgment numbers, retransmissions, and delta times—to reconstruct packet order with certainty.
- Apply practical Wireshark and tshark workflows to correlate captures from multiple vantage points and identify the true sequence of events in a TCP flow.
You Should Know:
- The Great Timestamp Deception – Why Your Clock Is Not Their Clock
Every network interface card (NIC) and operating system maintains its own notion of time. When you initiate a packet capture on two different machines—say, a client workstation and a server—each capture file’s timestamps are referenced to that specific machine’s system clock. Even with NTP synchronization, microsecond-level drift is inevitable, and without NTP, offsets can span seconds, minutes, or worse.
Consider this scenario: Capture Point A (client-side) records a packet at 10:00:00.100, while Capture Point B (server-side) records the same packet at 10:00:00.050 due to a 50-millisecond clock offset. If you naïvely sort by the absolute timestamp, you would conclude the server saw the packet first—a physically impossible outcome if the client originated the transmission. The Time column, therefore, is not a universal truth; it is a local approximation. This is precisely the challenge Chris Greer highlights in his Wireshark Labs training: “The Time column can mislead you because each capture point may have its own clock, start time, offset, or drift”【2†L9-L11】.
The solution lies in abandoning absolute timestamps as your primary ordering mechanism and instead relying on relative timing within each capture and TCP’s internal state machine. Each capture provides accurate deltas—the time between consecutive packets observed at that specific point—because these are measured by the same clock. These deltas are trustworthy. Absolute offsets between captures are not.
- TCP as Your Chronological Compass – Sequence Numbers, ACKs, and Retransmissions
TCP is a stateful protocol designed to ensure reliable, in-order delivery. This very design provides the analyst with an independent, clock-agnostic ledger of events. Every TCP segment carries a sequence number (SEQ) indicating the byte position of the data, and an acknowledgment number (ACK) indicating the next expected byte from the peer. These numbers are monotonically increasing and are governed by strict rules, making them the ideal foundation for reconstructing packet order.
Key TCP fields for multi-point ordering:
- SEQ/ACK numbers: These reveal the logical progression of a conversation. A packet with a higher SEQ number was sent after a packet with a lower SEQ number, regardless of what the timestamps say.
- Retransmissions: A duplicate ACK or a retransmitted segment with the same SEQ number signals that a packet was lost or arrived out of order. The timing of retransmissions relative to original transmissions is critical.
- Direction of travel: A packet observed at the client capture point that is sent from the client to the server must have originated at the client before it can be observed at the server. Conversely, a server-to-client packet must appear first at the server capture.
By cross-referencing these TCP artifacts across two capture files, you can establish a causal chain. If Capture B shows an ACK for a SEQ number that Capture A shows as having been sent 10 milliseconds later (according to A’s clock), you immediately know that B’s clock is ahead—and the true order is what TCP dictates, not what the timestamps display.
- Step‑by‑Step Guide: Correlating Two Captures of the Same TCP Flow
This hands-on workflow demonstrates how to determine packet order from two independent capture points without trusting absolute timestamps. The following steps assume you have two capture files: `client.pcap` and `server.pcap` from the same TCP conversation.
Step 1: Isolate the TCP Stream in Each Capture
In Wireshark, apply the display filter `tcp.stream eq X` (where X is the stream index) to each capture file. This filters out unrelated traffic, allowing you to focus solely on the conversation of interest.
Step 2: Export the Stream Data for Side‑by‑Side Comparison
Use Wireshark’s “Follow TCP Stream” feature to view the raw data. However, for granular analysis, export the packet list as CSV or use tshark to extract key fields:
tshark -r client.pcap -Y "tcp.stream eq 0" -T fields -e frame.number -e frame.time_relative -e tcp.seq -e tcp.ack -e tcp.len -e tcp.flags -e ip.src -e ip.dst -E header=y -E separator=,
Repeat for server.pcap. This gives you two structured tables with relative timestamps (from each capture’s start) and the critical TCP fields.
Step 3: Identify the First Packet in the TCP Handshake
The three-way handshake (SYN, SYN-ACK, ACK) is the unambiguous starting point. Locate the SYN packet in each capture. The capture that shows the SYN packet originating from the client is the client-side capture. The capture that shows the SYN packet arriving is the server-side capture. The absolute timestamp of the SYN in the client capture should, logically, be earlier, but if it isn’t, you now know the offset.
Step 4: Trace the SEQ/ACK Progression Across Both Files
Create a timeline using SEQ numbers. For each packet, note the SEQ, ACK, and payload length. The next packet from the same source should have SEQ = previous SEQ + previous payload length (unless retransmission or out-of-order delivery occurred). Match these progressions across the two files.
For example:
- Client capture shows packet 10: SEQ=100, ACK=200, Len=50.
- Server capture shows packet 15: SEQ=100, ACK=200, Len=50 (identical). This is likely the same packet observed at the server. The true order is that this packet was sent by the client (observed in client capture) before it was received by the server (observed in server capture), regardless of timestamp values.
Step 5: Detect and Resolve Retransmissions
If you see a packet with a SEQ number that was already acknowledged, it is a retransmission. The retransmission must have occurred after the original transmission. Use the relative timestamps within each capture to order these events locally, then cross-reference to see if the retransmission was triggered by a duplicate ACK from the other side.
Step 6: Reconstruct the Global Order
Build a merged event list ordered by TCP logic:
1. SYN (client → server)
2. SYN-ACK (server → client)
3. ACK (client → server)
4. Data segments in SEQ order
5. ACKs for received data
- Any retransmissions or duplicate ACKs in their logical position
This list is your ground truth. Compare it against the absolute timestamps to quantify the clock offset between the two capture points.
- Command‑Line Arsenal – Using tshark for Multi‑Point Correlation
For analysts who prefer the command line or need to automate this process, tshark provides powerful filtering and extraction capabilities. Below are essential commands for multi-point analysis on both Linux and Windows.
Linux/macOS (bash):
Extract SEQ/ACK and relative time for a specific stream tshark -r capture.pcap -Y "tcp.stream eq 0" -T fields \ -e frame.time_relative -e tcp.seq -e tcp.ack -e tcp.len -e tcp.flags.syn -e tcp.flags.ack \ -e ip.src -e ip.dst -E header=y -E separator=, Find all retransmissions in a capture tshark -r capture.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.time_relative -e tcp.seq -e tcp.ack Export full packet details for two captures and compare using diff tshark -r client.pcap -Y "tcp.stream eq 0" -T fields -e tcp.seq -e tcp.ack -e frame.time_relative > client_seq.txt tshark -r server.pcap -Y "tcp.stream eq 0" -T fields -e tcp.seq -e tcp.ack -e frame.time_relative > server_seq.txt diff client_seq.txt server_seq.txt
Windows (PowerShell):
Similar syntax, tshark works identically on Windows tshark -r capture.pcap -Y "tcp.stream eq 0" -T fields -e frame.time_relative -e tcp.seq -e tcp.ack -e tcp.len -e ip.src -e ip.dst -E header=y -E separator=,
Pro Tip: Use the `-z` statistics options in tshark to generate TCP stream graphs and sequence number plots, which visually reveal ordering anomalies:
tshark -r capture.pcap -z "flow,tcp,0"
This generates a sequential flow diagram of the TCP stream, highlighting retransmissions and out-of-order deliveries without relying on timestamps【2†L13-L15】.
- Real‑World Scenario – Two Capture Points, One TCP Flow, Three Packets
Let’s apply this methodology to a concrete example, inspired by Chris Greer’s challenge: “Can you determine packet order without trusting absolute timestamps? Two capture points. One TCP flow. Different perspectives”【2†L7-L8】.
The Setup:
- Capture A (client-side) and Capture B (server-side) both record the same TCP transfer.
- Capture A’s clock is 5 seconds behind Capture B’s clock.
- You observe the following packets:
| Capture | Relative Time | SEQ | ACK | Len | Direction |
|||–|–|–|–|
| A | 1.000 | 100 | 200 | 100 | C→S |
| B | 0.500 | 100 | 200 | 100 | C→S |
| A | 1.050 | 200 | 300 | 0 | S→C |
| B | 0.550 | 200 | 300 | 0 | S→C |
| A | 1.100 | 200 | 300 | 50 | C→S |
| B | 0.600 | 200 | 300 | 50 | C→S |
Analysis:
- Packet 1 (SEQ=100, Len=100) and Packet 2 are the same segment—Capture A sees it at 1.000, Capture B at 0.500. Since B’s clock is ahead, the true send time is ~1.000 (A’s time). The packet was sent by the client, so it must appear in A before B. Thus, A’s timestamp is the “true” send time.
- Packet 3 (SEQ=200, ACK=300, Len=0) is an ACK from server to client. It must be generated by the server after it receives the data. Capture B shows it at 0.550, Capture A at 1.050. The true order is: data packet (A:1.000) → ACK generated by server → ACK observed at B (0.550 B-time) → ACK observed at A (1.050 A-time).
- Packet 5 is another data segment (SEQ=200, Len=50). Note the SEQ is 200, which is the same as the ACK in Packet 3. This is a new data segment from client to server. It must occur after the ACK was sent (since the client received the ACK for the previous data). The true order is: ACK (B:0.550, A:1.050) → new data (A:1.100, B:0.600).
Correct Global Order:
1. Data segment 1 (SEQ=100, Len=100) – C→S
- ACK for data 1 (SEQ=200, ACK=300) – S→C
3. Data segment 2 (SEQ=200, Len=50) – C→S
This order is derived entirely from TCP semantics, not from the absolute timestamps【2†L13-L15】.
6. Best Practices for Multi‑Point Capture Deployment
Preventing timestamp chaos starts before you even press the “Start” button. Implement these operational best practices to minimize ambiguity and streamline your analysis.
Synchronize Clocks Rigorously: Deploy NTP on all capture devices and verify synchronization using `ntpq -p` (Linux) or `w32tm /query /status` (Windows). Document the offset of each device relative to a reference time server before starting the capture. This gives you a baseline correction factor.
Use Relative Timestamps in Analysis: Within Wireshark, change the Time Display Format to “Seconds Since Beginning of Capture” (View → Time Display Format → Seconds Since Beginning of Capture). This forces you to think in relative terms and reduces the temptation to rely on absolute wall-clock times.
Annotate Capture Files with Metadata: Include the capture start time, device hostname, timezone, and NTP offset in the capture file’s comment field (Edit → Comment). This metadata is invaluable when correlating captures days or weeks later.
Capture at Strategic Points: Deploy captures at network boundaries—client-side, server-side, and at critical network devices (firewalls, load balancers). The more vantage points you have, the easier it is to triangulate the true sequence of events. As Chris Greer emphasizes, these are “hands-on labs built around real network traffic—focused on understanding what’s actually happening, not just theory”【2†L17-L19】.
- Advanced Mitigation – Taming Clock Drift with Wireshark’s Time Shift
Wireshark provides a built-in tool to adjust timestamps of an entire capture file, allowing you to align clocks post-capture. This is useful when you have a known reference point, such as a synchronized event like a TCP handshake.
Step 1: Open the capture file you wish to adjust.
Step 2: Navigate to Edit → Time Shift.
Step 3: Choose “Shift time by a specified amount” and enter the offset (in seconds) required to align a specific packet with its counterpart in the other capture.
Step 4: Apply the shift. The entire file’s timestamps will be adjusted, making side‑by‑side comparison more intuitive.
Warning: Time shifting is a cosmetic adjustment. It does not fix the underlying issue of clock drift. For forensic integrity, always keep the original, unmodified capture files and document any adjustments made.
What Undercode Say:
- Key Takeaway 1: Absolute timestamps are unreliable across multiple capture points due to clock drift, offset, and lack of synchronization. Trust TCP’s internal state—sequence numbers, acknowledgments, and retransmissions—as your primary ordering mechanism. This is not a theoretical nuance; it is a practical necessity for accurate incident reconstruction.
- Key Takeaway 2: Multi-point analysis is a skill that separates novice packet analysts from experts. It requires disciplined workflows, command-line proficiency with tshark, and a deep understanding of TCP state machines. The ability to correlate captures from client and server perspectives without being misled by timestamps is what enables you to pinpoint the exact moment of compromise, identify the source of a performance bottleneck, or exonerate a falsely accused system.
Analysis: The challenge Chris Greer poses is deceptively simple yet profoundly revealing. Most analysts, when confronted with two captures of the same flow, will instinctively sort by the Time column and call it a day. This approach fails in real-world environments where NTP is misconfigured, virtual machines have unstable clocks, or captures are taken from devices in different time zones. The TCP-centric methodology outlined here is not just a classroom exercise—it is the standard of practice for forensic investigators at major security firms and incident response teams. The Wireshark Labs and WCA certification courses that Greer promotes are explicitly designed to drill these skills through hands-on, realistic traffic scenarios, moving beyond theory into muscle memory【2†L17-L19】. Investing in this training, especially with the current $100 discount, is a strategic move for any security professional who relies on network evidence to make high-stakes decisions.
Prediction:
- +1 The increasing adoption of cloud-1ative architectures and microservices will amplify the need for multi-point packet analysis, as distributed tracing and sidecar proxies generate multiple capture points per transaction. Analysts who master timestamp-agnostic correlation will become indispensable.
- +1 Wireshark and tshark will continue to evolve with AI-assisted correlation features, but the fundamental TCP logic will remain the bedrock. Automation will augment, not replace, the human analyst’s ability to reason from protocol behavior.
- -1 Failure to address clock synchronization in enterprise deployments will lead to more frequent misdiagnoses of security incidents, potentially resulting in delayed response times and overlooked indicators of compromise.
- -1 As network speeds increase to 400 Gbps and beyond, the volume of captured data will make manual multi-point analysis impractical without robust tooling and disciplined methodologies. Organizations that neglect this skill will find themselves overwhelmed and unable to trust their own packet evidence.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Cgreer Just – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
