On Mar 3, 2013, at 1:51 PM, Christopher Maynard <christopher.mayn...@gtech.com> wrote:
> I think there is a difference between displaying the packets matching the > filter > and saving the packets matching the filter to another pcap file. In the > former > case, Wireshark does not display packets that don't match the display filter; > I > think tshark should behave the same way. Yeah I agree - I'll make that change to my patch regardless of the outcome of this discussion. > And currently Wireshark does not allow you *NOT* to save those dependencies - > From Jeff's commit message, "Also, this behavior is always the case: you can't > save the displayed packets without their dependencies (I don't see why this > would be desirable)." So, tshark might as well act similarly. I suggest > dispensing with the -Y option and just save all packet dependencies when using > the -2 and -w <outfile> options. Displaying packets should not change. I'm fine with that too... but I should note that the current tshark '-2' option is really much more like Wireshark's *read* filter than *display* filter: 1) It numbers the matching frames as 1,2,3 even if they're not the first/sequential frames in the physical file. 2) When exporting/writing out to a file, it does NOT include the fragments. Both of those are exactly what Wireshark's read filter does as well. Jeff's change doesn't change that - only if the fragments were in the frame list can it export them, and they'll only be in the frame list if there was no read filter, or if the fragment frame also matched the read filter. His change just made it so that fragment frames filtered out by a *display* filter would still be exported, but that works because the fragments are in the frame list just not in the GUI's packet list store.* -hadriel * by "frame list" I mean the frame data radix tree holding all frames regardless of being shown or not, and by "packet list store" I mean the GUI widget's table of PacketListRecords being shown. At least that's what I think the code does, but I could easily be wrong. :) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
