 | 1 | initial version |
The packet number is based on the order in which the packets appear in the capture file (for a live capture, packets are still written to a file, but they're written in the order in which they're delivered to libpcap/WinPcap/Npcap).
From the ".exe", this is presumably Windows; the default time stamp mechanism used by both WinPcap and Npcap doesn't give high-resolution tie stamps - note that all digits after the first 3 following the decimal point are 0, so that's a resolution of .001 seconds. That's why they appear to have arrived at the same time.
(Note also that, on most if not all platforms on which Wireshark can capture packets, a packet may be time stamped some amount of time after it's received, so time stamps aren't very precise.)
| | 2 | No.2 Revision |
The packet number is based on the order in which the packets appear in the capture file (for a live capture, packets are still written to a file, but they're written in the order in which they're delivered to libpcap/WinPcap/Npcap).
From the ".exe", this is presumably Windows; the default time stamp mechanism used by both WinPcap and Npcap doesn't give high-resolution tie stamps - note that all digits after the first 3 following the decimal point are 0, so that's a resolution of .001 seconds. That's why they appear to have arrived at the same time.
(Note also that, on most if not all platforms on which Wireshark can capture packets, a packet may be time stamped some amount of time after it's received, so time stamps aren't very precise.)precise. Unless you use hardware capture nodes with hardware time stamping, e.g., ProfiTap)
