ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] tshark option for reassembled fragment output

From: Evan Huus <eapache@xxxxxxxxx>
Date: Fri, 29 Mar 2013 11:15:49 -0400
On Thu, Mar 28, 2013 at 10:27 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Mar 28, 2013, at 1:37 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>
>> On Thu, Mar 28, 2013 at 12:41 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>>
>>> 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.
>
> Sounds fine to me too.

I've updated the bug with a link to this discussion and a quick
summary. Were you planning to code this or should I add it to my todo
list?

Cheers,
Evan