Re: tshark option for reassembled fragment output

[Evan Huus <eapache () gmail com>]

On Sun, Mar 3, 2013 at 12:31 PM, Hadriel Kaplan <HKaplan () acmepacket com> wrote:
> On Mar 3, 2013, at 9:57 AM, Evan Huus <eapache () gmail com> wrote:
>
> > Right now, wireshark has three CLI filter flags: -R, -d, -f.
> > -d is available through the 'filter' field in the file->open dialogue
> > -f is available through the 'capture filter' field in the
> > capture->options dialogue
> > -R is not available in the GUI at all?
>
> No I believe in the current version of Wireshark it's this:
> -d is the Wireshark *display* filter, same as shown in the toolbar or 'Analyze->Display Filters...'
> -f is as you say
> -R is the Wireshark *read* filter, same as through the 'Filter:' field in file->open

Right. I saw the pre-populating of the display filter field and got confused.

> For some reason when the read filter is done in the file->open dialog box instead of through -R, wireshark also 
> happens to pre-populate the display filter field once the file is opened, presumably as a reminder?  But clearing the 
> display filter doesn't make the other frames appear, since the file's already been opened with only the frames 
> matching the read filter.  And using -R from the command line doesn't pre-populate the display filter field in the 
> opened file.
>
> Currently in tshark the '-R' alone doesn't behave like anything in Wireshark, but '-R -2' two-pass behaves like 
> Wireshark's -R read filter; whereas my patch behaves like Wireshark's '-d' display filter.
>
>
> > > 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.  But it's got the performance benefit of only doing one pass.  I'm not sure if that 
> > > matters to many people, but I would think it would to someone.(?)
> >
> > I would think that whatever tshark's filter flag is, it ought to
> > behave just like wireshark's display filter. It should be possible to
> > do that in still only one pass?
>
> I don't see how - the filter matching can happen on the second frame/packet of a pair of fragments, for example, and 
> you've already passed by the initial fragment by that time.  So right now my tshark patch uses the 2-pass model by 
> adding all frames to the frame-list/radix-tree in the first pass and marking the dependency flag of previous frames 
> in the list when the filter matches; then in the second pass it prints the frames that are marked for dependency or 
> pass the filter.  In the second pass I'm not sure the filter needs to be applied again, but that's what the code did 
> before so there's probably some good reason for it.

Hmm, yes. So the one-pass mode should behave the same as wireshark
except for fragmented packets then?

I think, in general, I'm still in favour of getting rid of the read
filter. The file->open filter field which currently acts (sort of)
like -R can instead act like Wireshark's current -d: prepopulating the
display filter, but not actually removing the other packets from
consideration (so that clearing the display filter shows them again).

There doesn't seem to be a coherent and usable behaviour for -R when
dealing with fragmented packets.

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