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