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?
