Timestamp values from VMHOST likely moved by VMotion
I have two capture files of the same traffic between a pair of Windows servers. One capture file is from Wireshark running on one of the Windows virtual hosts. The other capture file is from a SPAN port on a switch close to the other Windows system. The capture covers a roughly 24 hour period. The purpose of the captures was to isolate where our connection failures were happening.
I extracted the SYN packets from both capture files and compared their packet timestamps, matching on source and destination ports and the packet sequence number (actual, not relative). The delta time for the same packet starts out at 80 milliseconds. After an hour or so the delta becomes 7.6 seconds and stays that way for 23 hours. Then within the next hour the delta time for the same packet jumps to 2 minutes, then 10 minutes, then 30 minutes.
We suspect the Wireshark time stamps are incorrect, because it is the only movable object in this scenario - it moves when the virtual server moves. But even so, I can't explain away a 30 minute difference for the same packet. And I was told all servers in the data center are time sync'd to the same NTP server.
The timestamps are generated by the capture library, usually WinPcap or npcap on Windows, which are you using?
I believe they downloaded the standard Wireshark install which would have loaded WinPcap. Looking through my old files we had an issue with WInPcap years ago on certain workstations that one of my co-workers diagnosed. WinPcap exhibits this issue on certain workstations, where the timestamping clock progresses more slowly than the wall clock. For example, a one-hour capture may contain timestamps that span only 20 minutes, with the first packet’s timestamp being accurate and the last packet's timestamp being 40-minutes shy of its actual time.
He found two solutions: a registry setting for NPF (see http://seclists.org/wireshark/2010/Au...) and a system timer boot file modification.
My current captures exhibit the same issue -- the Wireshark timestamps are earlier than the network derived timestamps - though the drift is certainly not linear.
As the reference link notes, WinPcap can either use the lower resolution system time which should stay in sync, or the higher resolution performance counters which can drift.
You could try uninstalling WinPcap and installing npcap which is stable enough to be distributed with Wireshark in the upcoming 3.0 release, but I don't know if npcap has improved the handling of time over Winpcap. Wireshark 2.6.x runs quite happily with npcap.