Wireshark-dev: Re: [Wireshark-dev] tshark option for reassembled fragment output
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Christopher Maynard <Christopher.Maynard@xxxxxxxxx>
Date: Mon, 4 Mar 2013 05:58:16 +0000 (UTC)
Evan Huus <eapache@...> writes:

> 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 think this is a bug.  :)  When using a read filter, Wireshark should only be
working with the frames that passed the read filter.  Obviously if there's only
a single frame, Wireshark shouldn't know anything about other segments from
frames within the file on disk but not loaded into Wireshark.