Hm, let me formulate then the question other way round:
What is the added value of having separate notion of packets' numbers based
on sequence of their delivery from OS level apart from maybe pointing
to some bug in OS?
/wbr
Ariel Burbaickij
Ariel Burbaickij wrote:
> If I correctly understood your question:
> yes, I do change sort order of packet display
> by using different sorting keys like timestamp
> or number. Use of word filter in this sentence from me:
> "...when I filter on packets' number and then on time..."
> is misleading what is meant is sorting.
Yes - "filter" should be used for display filters, not for sorting, as
many of us are used to interpret it as referring to display filters.
So what happened was (translating):
>>> Hello all,
>>> following for me somehow unexpected result:
>>> when I sort on packets' number and then on time
>>> results are different and sorting on time produces
>>> not ordered set of packets' numbers but they are
>>> mixed like in e.g. 1, 2, 7, 8, 4,3 etc.
I'm not sure our packet sorting algorithms are stable, so if two packets
have the same time stamp, sorting by the time stamp might not preserve
the order they had before that sort.
In addition, as per my earlier mail:
>> 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.
even if all packets have different time stamps, if M > N, packet M might
not have a larger time stamp than packet N, so sorting by time stamp
could put the packets in a different order than sorting by packet number.
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
