On Jul 20, 2019, at 12:29 PM, phreakocious <phreakocious@xxxxxxxxx> 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..