On Jul 10, 2007, at 2:16 PM, Ariel Burbaickij wrote: > Hello all, > following for me somehow unexpected result: > when I filter on packets' number and then on time > results are different and filtering on time produces > not ordered set of packets' numbers but they are > mixed like in e.g. 1, 2, 7, 8, 4,3 etc. > Without delving into the code: > Is there is more to the logic: > the moment packet is timestamped next unassigned > number is granted to its packet number?
Absolute packet time stamps are recorded in the capture file; the packet number is *implicit* in the capture file, i.e. the first packet in the file has the number 1, the second file has the number 2, etc.. For libpcap-format files: The time stamping occurs, for most platforms, in the kernel; the kernel-assigned time stamp is in the data read by libpcap. The one exception that comes to mind is HP-UX, where the kernel doesn't assign a time stamp, so libpcap has to use the current time. Packets are written to the capture file in the order in which they're delivered to libpcap. Packet capture mechanisms do not necessarily guarantee that the N+1st packet delivered to libpcap has a time stamp >= that of the Nth packet delivered to libpcap - I'd argue that not making such a guarantee (assuming nobody explicitly moves the system clock backwards; if that happens, all bets are off) is a bug, but I think some versions of Linux, for example, are buggy in that sense. For all file formats, once a capture file is read, the absolute time stamp of a packet, and its packet number, don't change. Are you changing the sort order of the packet display? _______________________________________________ Wireshark-users mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-users
