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.
