[Evan Huus <eapache@xxxxxxxxx>]

On Mon, Mar 4, 2013 at 1:01 AM, Christopher Maynard
<Christopher.Maynard@xxxxxxxxx> wrote:
> Hadriel Kaplan <HKaplan@...> writes:
>
>> The *tshark* legacy '-R' by itself (without the '-2') is also fairly
> confusing.  It doesn't behave as a
>> Wireshark read filter or display filter.
>
>
> No, unfortunately it behaves as both a read filter and display filter.  I think
> tshark needs a display filter option, regardless of whether Evan's suggestion of
> eliminating read filters is implemented or not.

Agreed.

On Mon, Mar 4, 2013 at 12:58 AM, Christopher Maynard
<Christopher.Maynard@xxxxxxxxx> wrote:
> Evan Huus <eapache@...> writes:
>> You get a single frame (numbered frame 1) that displays as "2
>> Reassembled TCP Segments (1765 bytes): #1(1460), #1(305)". There's no
>> explanation in the UI as to why we now seem to have three different
>> "frame 1"s floating around (I understand why, but I'm just saying it
>> leads to a very confusing interface).
>
> I think this is a bug.  :)  When using a read filter, Wireshark should only be
> working with the frames that passed the read filter.  Obviously if there's only
> a single frame, Wireshark shouldn't know anything about other segments from
> frames within the file on disk but not loaded into Wireshark.

I tend to agree, but that would be very hard to do. Fragment
reassembly (and request/response tracking) happens well before any
filtering can be applied, which is what leads to the above case. I'm
not sure there's a way to make this behave sanely without doing a
whole rework of the flow of our dissection process.

I'm not against the concept of a read filter generally, it's just that:
- the benefit it provides is fairly minimal over just a display filter
and re-saving (if you're on a space-restricted device I'd be surprised
if you had tshark at all - you'd be more likely to stick with tcpdump
I'd think)
- I don't know of a way to make it behave sanely without a *lot* of work

On Mon, Mar 4, 2013 at 3:29 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Mar 3, 2013, at 10:00 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>> I *really* do not like the renumbering of frames that the read filters
>> currently do (-R in wireshark, -2R in tshark). I find it confusing and
>> not useful entirely apart from the fact that there is no graceful way
>> for it to handle reassembly dependencies (see my "frame 1 depends on
>> frames 1 and 1" example earlier). Does anybody know why it was added
>> in the first place? It seems to me that it adds very little that was
>> not already available by using a regular display filter and saving the
>> results to a new file.
>
> I think it lets you load a very large capture file with only the frames you care about and avoid the long-wait-cycles during displaying, changing the display filter, and running stats and such... though I don't have a very large pcap to test that theory on.  The number of times the frames in the frame list are re-dissected during normal use is impressive. :)

We have a whole boatload of subtle bugs in that area. See, for example, #8273.

On Mon, Mar 4, 2013 at 1:31 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
> On Mar 3, 2013, at 10:00 PM, Evan Huus <eapache@xxxxxxxxx>
>  wrote:
>> We can't make -2 the default for tshark doing live capture, as that
>> would require us to buffer all output until the capture is finished,
>> which isn't very helpful. We might want to make it default when
>> reading from a file, but then the two cases will behave subtly
>> differently and there's a possibility for people to become confused.
>
> Sorry I should have been clearer... I wasn't talking about live capture.
> The current -R isn't supported for live capturing when writing to a file, unless bug 2234 changes that.  When you're NOT writing to a file but just stdout, there's no real benefit for detecting fragment future-dependency, because you're not going to print out the fragments anyway.  There also isn't a benefit to request/response tracking - except for an extreme case of doing a '-R "dns.response_in > 1"' type thing.
>
> So basically we could make it the new default whenever a '-R' is used and either '-r', or '-w', or both are used; but have it do the current one-pass when neither are used, or when '-1' is set.  Clear as mud?  :)

I think so (assuming some new 'display filter' flag for tshark behaves
the same as -R in this respect). Then there's just the question of
whether we want tshark to be consistent within itself, or more
consistent with Wireshark by default. My worry with making -2 default
when we can is that it leads to this big complicated chain of logic
which is hard to get right on our side, and confusing to explain to
the user in the help page. I foresee a lot of "Oh, you wanted to use
this obscure flag as well? Then you have to manually specify -2 to get
that behaviour which otherwise occurs automatically. Why? Well, it's
complicated, read this multi-page mailing list discussion."

Sticking with one-pass by default unless -2 is specified feels
conceptually safer to me. It also permits users to do a two-pass
buffered live capture if they really want to, though I'm not sure
that's actually a good reason.

Evan