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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
