https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3872
--- Comment #1 from Sake <sake@xxxxxxxxxx> 2009-12-23 01:28:31 PST ---
(In reply to comment #0)
> Am I doing anything
> wrong or have I misunderstood something? I expected that all filter expressions
> would give the same number of packets.
No, you are not doing anything wrong, but things can get a little complicated
when tcp allows a higher layer protocol to reassemble data. So first of all, if
you turn off reassembly (in TCP protocol preferences deselect "Allow
subdissector to reassemble TCP streams"), you will see that there will be no
difference in the count of packets when filtering and then reloading the file.
So why does reassembly change things? Well, for that you need to know that
Wireshark reads the file sequentially when it is loaded. Then when filtering is
applied, it reads the file again, but *without* losing all it's state
information (which is kept on a per conversation and/or per packet basis). This
means that a packet can be dissected differently between the first pass and the
second pass (as on the second pass Wireshark knows things about the packets
following the current packet that it did not know on the first pass).
When loading a file when a display filter is enabled, the filtering takes place
on the first pass (to save time) and when a filter is entered when the file
already is loaded, the filtering takes place on the second pass.
tshark only has one pass through the file (at the moment, there are votes to
make it a two pass process too) so it will give the same results as reloading
the file in wireshark when a display filter is active.
I have not worked out the whole tracefile, but it looks like you have
out-of-order frames that might be responsible for the different behavior
between the two passes.
Do you encounter this problem much? If not, I want to suggest closing this bug
as an inconvenient sequence of packets in combination with reassembly.
Cheers, Sake
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
