On Sun, Mar 3, 2013 at 12:31 PM, Hadriel Kaplan <hkap...@acmepacket.com> wrote: > > On Mar 3, 2013, at 9:57 AM, Evan Huus <eapa...@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-requ...@wireshark.org?subject=unsubscribe
