Re: tshark option for reassembled fragment output

[Hadriel Kaplan <HKaplan () acmepacket com>]

On Mar 28, 2013, at 7:36 AM, Evan Huus <eapache () gmail com> wrote:

> - We need to keep '-2' around for the case where the user wants to do
> 2-pass analysis without any filtering.

Agreed, and that's still done/supported by the patch.


> - Buffering is unfortunately necessary behaviour, but still confusing.
> We should impose it only if the user explicitly asks for it (with -2).

I'm cool with that, or anything really - the reason I made it the default for '-Y' in the patch is because (1) in 
one-pass mode it would be identical to '-R' anyway so redundant, and (2) it seemed like the least-surprising behavior 
for the user in the sense that it would have the fewest issues/glitches.


> It's possible we may want to go as far as forbidding -R without -2
> just to enforce the conceptual distinction. This would have the
> advantage that then -R would *always* renumber packets, (while -d
> never does) which is at least a win for consistency.

Huh, that's an interesting suggestion.  I kind of like it, because you're right that would at least be consistent with 
regards to the re-numbering stuff.  But we'd be breaking people's bash/sed/whatever scripts that use the '-R' with 
tshark without the '-2'.

How about this: we make '-d' usable in one-pass or two-pass modes, based on '-2' etc.; and we make the '-R' 
automatically-and-only be for two-pass mode, implicitly enabling '-2'.  I know you dislike tshark buffering unless 
explicitly told to do so, but I really think people don't perceive the difference of buffering vs. not in tshark except 
for the performance impact - what they perceive is whether the output is what they expected it to be.  Making them add 
another option switch that basically means "make it work", is kinda silly. :)

-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