Wireshark mailing list archives
Re: tshark option for reassembled fragment output
From: Evan Huus <eapache () gmail com>
Date: Thu, 28 Mar 2013 13:37:28 -0400
On Thu, Mar 28, 2013 at 12:41 PM, Hadriel Kaplan <HKaplan () acmepacket com> wrote:
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'.
We're going to be breaking -d anyways, but that's what major version numbers are for :) In most cases, scripts using -R without -2 should be changed to use -d, not to use -2R, especially if the script depends on the non-buffering behaviour.
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. :)
I'd be alright with this. Perhaps, however, have -R on its own behave as it currently does (and as 1-pass -d will), but print a warning to the effect of "-R on its own is deprecated. Did you mean -2R or -d?". This would mean that scripts using -R will continue to work as-is (unless they choke trying to parse the warning, but that's unlikely since it will be to stderr not stdout). At some future date we can decide to either disable single-pass -R entirely or have it imply -2. Cheers, Evan ___________________________________________________________________________ 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
Current thread:
- Re: tshark option for reassembled fragment output, (continued)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 28)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 28)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 28)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 28)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 29)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 29)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 28)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)