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

[Evan Huus <eapache@xxxxxxxxx>]

On Thu, Mar 28, 2013 at 1:18 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Mar 27, 2013, at 10:38 PM, Evan Huus <eapache@xxxxxxxxx>
>  wrote:
>
>>> So why make it optional?
>>
>> Because -2 causes tshark to buffer, which we shouldn't be imposing on
>> the user 'by accident'. Additionally, if we keep -2 a separate option
>> then -d will be usable during a live capture, which fixes another
>> long-standing issue in tshark.
>
> You lost me... why would '-d'/'-Y' be usable during a live capture, but '-R' not?
>
> I thought '-R' was only *unusable* with live capturing when the '-w' writing output file was also set, on purpose due to concerns of privilege separation (ie, bug 2234).  I put the same restriction in my patch for '-Y': it can't be used if both live-capture and writing to file are set.

I clearly shouldn't be writing emails that late at night :P (I'm also
currently looking at bug #8317 which is in the same code neighbourhood
as both this issue and bug #2234, and somehow I got them all mixed
up). Live capture doesn't even enter into it, you're right. Allow me
to try that again:

- We need to keep '-2' around for the case where the user wants to do
2-pass analysis without any filtering.
- Buffering is unfortunately necessary behaviour, but still confusing.
We should impose it only if the user explicitly asks for it (with -2).
- While -d and -R would be effectively identical during 1-pass
analysis, it seems to me that conceptually -R is the odd one out.
There's no need to do a read filter if you're never going to look at
the packets again, while you might still want to control what is
displayed.

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.