On Jul 20, 2019, at 12:29 PM, phreakocious <[email protected]> wrote:
> Thank you for the detailed reply. I'll file the bug.
>
>> That's only inconsistent or unintuitive to people who somehow think that
>> popping up a context window on a column that says "TCP" should do anything
>> other than apply a display filter of "tcp".
>
> They are out there, I assure you.
They don't understand that their *real* complaint is that the column says "TCP"
rather than "HTTP" or "NFS" or "SMB" or "SMTP" or... - if they think that
requesting a display filter for an ACK to a TCP segment containing HTTP traffic
should give "http" as the filter, presumably that means they think the packet
is "really" HTTP. And I think people *have* asked for that.
And perhaps what's really needed there is the ability to look at network
traffic from multiple different protocol layers, so that you could, for
example, have a view that would show one row in the packet list for each HTTP
request/reply, or each NFS request/reply, or each SMB request/reply, or..., so
that
1) transport-layer-only packets (such as ACK-only packets in TCP)
wouldn't appear;
2) packets dissected only at layers below the transport layer (such as
most fragments of a fragmented IP datagram) wouldn't appear;
3) if there are multiple requests or replies in a single TCP segment,
they would have *separate* rows in the summary list;
4) if a request or reply takes multiple TCP segments, it would take up
only one row in the summary list;
etc..
___________________________________________________________________________
Sent via: Wireshark-users mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
mailto:[email protected]?subject=unsubscribe
