On Sun, Mar 3, 2013 at 1:07 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>
> Yeah but getting rid of Wireshark's read filter is a much bigger change, if you mean getting rid of it within Wireshark's GUI as well. On the other hand it might be less confusing even within Wireshark to have fewer places/ways to apply filters.
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?
> 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?
For consistency, I would suggest that both tshark and wireshark take
only two filter flags:
-d using wireshark dfilter syntax
-f using libpcap syntax
Tshark's -d uses only one pass unless -2 is specified. In either case
it should behave as close as possible to Wireshark's display filter.
This would mean moving tshark's current -d flag to something else (-R
would be available, though it wouldn't make a lot of sense).
> -hadriel
>
>
> On Mar 2, 2013, at 10:50 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>
>> My instinct is to get rid of the 'read filter' concept entirely. I
>> find it's behaviour in wireshark very confusing, especially in the
>> reassembly cases we're considering. For example, take the capture from
>> bug #8223 and run
>>
>> ./wireshark -R "ip.src == 10.90.130.69 && ip.dst == 10.90.130.66 &&
>> tcp.flags.push == 1" ~/testcapture.pcapng
>>
>> 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 would prefer to simplify by removing -R from wireshark, changing
>> 2-pass analysis in tshark to not renumber the frames, and then not
>> adding a new flag for the proposed feature. If someone really wants to
>> do a 'read filter' style thing they can pipe two instances together,
>> or save and reopen the filtered file.
>>
>> Evan
>>
>> On Sat, Mar 2, 2013 at 12:50 AM, Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx> wrote:
>>> Howdy,
>>> About a year ago r41216 fixed bug 3315, so that fragments which contributed to a reassembled PDU that matched a display-filter would be exported along with the filter-matching PDU's final frame. I.e., suppose I have a display-filter of 'sip' and frame #3 is the only frame displayed because it matches the filter; but it was really the reassembled PDU of frames #2 and #3 because they were fragmented IP or separate TCP segments... then both frames #2 and #3 would be exported even if I choose to only export "displayed" frames.
>>>
>>> That fix was great, but only done in Wireshark not tshark. Even in two-pass mode (opt '-2'), tshark won't print/write the fragments which contributed to the reassembled PDU. Thus there're bugs 8223 and 8101, and http://ask.wireshark.org/questions/18975
>>>
>>> I have a patch to fix it, using the same function code as Wireshark. It only works in two-pass mode, since one has to do two passes to accomplish it; but when enabled it changes how the original '-2' two-pass mode displays its output.
>>>
>>> So the tricky thing, and the reason for this email, is whether it needs a new option such as '-Y', or even '-Y <display filter>'. I currently have it as a new '-Y <display-filter>', which automatically does a two-pass analysis and ignores the -2 option, and prevents the user from doing both -R and -Y at the same time by error-ing out. I should probably have it error-out if the user indicates '-2' at the same time, too. It leaves the current behavior of '-R' and '-2' unchanged when they're used as before.
>>>
>>> Does anyone have any preference/better-idea for how to indicate this new option?
>>>
>>> -hadriel
>>>
>>> ___________________________________________________________________________
>>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>> Archives: http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe