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.
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.(?) -hadriel On Mar 2, 2013, at 10:50 PM, Evan Huus <eapa...@gmail.com> 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 <hkap...@acmepacket.com> > 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@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 > ___________________________________________________________________________ > 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 ___________________________________________________________________________ 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
