Re: tshark option for reassembled fragment output

[Hadriel Kaplan <HKaplan () acmepacket com>]

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

> Hmm, yes. So the one-pass mode should behave the same as wireshark
> except for fragmented packets then?

And except for response frame referencing in request frames, which I think was the reason the two-pass mode was added 
to begin with.  E.g., if you open a DNS capture file, the DNS request will have a 'dns.response_in' field that 
identifies the frame its response is in.  So that also requires two passes obviously.


> I think, in general, I'm still in favour of getting rid of the read
> filter. The file->open filter field which currently acts (sort of)
> like -R can instead act like Wireshark's current -d: prepopulating the
> display filter, but not actually removing the other packets from
> consideration (so that clearing the display filter shows them again).

But that's already available when you fill in the display field in the toolbar before opening a file. (though there's 
bug 8344 that it gets cleared sometimes from the toolbar box once the file is opened, but it's still being applied)

Although I guess letting the user fill in the display filter within the file->open dialog box as well has a nice 
usability aspect.  That file->open Filter field should be pre-populated with what's in the toolbar though, and if 
changed then replace what's in the toolbar too.


> There doesn't seem to be a coherent and usable behaviour for -R when
> dealing with fragmented packets.

Right but I think many people use tshark in a simple manner, just as a form of ngrep.  When just used to output to the 
screen/stdout, -R shows the reassembled packet details correctly, and doing only one pass it's faster.  The part that 
always causes confusion is when they do that and also choose to export the results into a file, because then that file 
won't have the fragments and when opening that new file with Wireshark, it won't be able to reasssemble to dissect.  Or 
they get confused if they choose certain fields that don't get populated with a single-pass model.

I think the real problem is what the "default" behavior is.  You have to know to do a '-2' to get what you expect; 
instead, there should be a '-1' option to only do one pass for those who care about the performance difference and 
don't care about fragments.  In other words, we should do the 'safest' thing by default, and the more-optimal-but-buggy 
thing only when explicitly told to do so.

-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