Xu nanxuan wrote:
My question is just like the title. Is the time consistent with the
system time that is shown in the Taskbar of Windows OS?
"Consistent" in what sense?
If you're capturing on a regular network adapter, the time stamp comes,
as far as I know, from the same operating system timer that supplies the
current time to user-mode code such as the taskbar code, so it should be
consistent in that sense.
For captures done by Wireshark (or tcpdump/WinDump, or any other program
using libpcap/WinPcap), the time stamp is in seconds and microseconds
since January 1, 1970, 00:00:00 UTC - i.e., the time stamps in the
capture file are not in local time, they're in Universal Time (well,
maybe TA1, but we won't worry about leap seconds here :-)).
If you are reading a capture that was done on a machine in a different
time zone, the time stamps will be displayed as time stamps in the time
zone of the machine on which you're reading the capture, not in the time
zone of the machine on which the capture was done.
And another question: Take the folollowing two lines for example:
==========================
time1 server->client packetinfo1
time2 client->server packetinfo2
==========================
If the wireshark is installed on the client side, then it's easy to
understand how time1 can be captured:when packet arrives at client, the
wireshark record the time1 in some way.
However, how does wireshark know time2? time2 means that the packet
arrives at server at time2,
No, time2 means that the host capturing the packet saw the packet at
time2. If the host sent the packet, that's the time when the packet was
sent. If Wireshark is running on a third machine capturing
promiscuously, that's the time when *it* received the packet.
Furthermore, a time stamp isn't necessarily the time when the packet
arrives at the host; it's the time when the code doing the capturing
sees the packet. For packets that the host receives, that happens after
any interrupt latency and after any processing done by the networking
driver and networking stack before the time stamping is done.
Furthermore, note that the networking adapter and driver might be
"batching" packets, which adds an additional delay between the arrival
of the packet at the adapter and the driver seeing the packet.
