On Sun, Mar 3, 2013 at 12:31 PM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> On Mar 3, 2013, at 9:57 AM, Evan Huus <eapache@xxxxxxxxx> 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
