Re: tshark option for reassembled fragment output

[Hadriel Kaplan <HKaplan () acmepacket com>]

On Mar 3, 2013, at 10:00 PM, Evan Huus <eapache () gmail com> wrote:

> === filtering ===
>
> I *really* do not like the renumbering of frames that the read filters
> currently do (-R in wireshark, -2R in tshark). I find it confusing and
> not useful entirely apart from the fact that there is no graceful way
> for it to handle reassembly dependencies (see my "frame 1 depends on
> frames 1 and 1" example earlier). Does anybody know why it was added
> in the first place? It seems to me that it adds very little that was
> not already available by using a regular display filter and saving the
> results to a new file.

I think it lets you load a very large capture file with only the frames you care about and avoid the long-wait-cycles 
during displaying, changing the display filter, and running stats and such... though I don't have a very large pcap to 
test that theory on.  The number of times the frames in the frame list are re-dissected during normal use is 
impressive. :)

-hadriel

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe