Re: tshark option for reassembled fragment output

[Christopher Maynard <Christopher.Maynard () gtech com>]

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.


___________________________________________________________________________
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