Re: tshark option for reassembled fragment output

[Evan Huus <eapache () gmail com>]

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 () 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-request () 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-request () wireshark org?subject=unsubscribe