Re: "apply/prepare filter" from the protocol column context menu unavailable

[phreakocious <phreakocious () gmail com>]

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.

On Fri, Jul 19, 2019 at 3:19 PM Guy Harris <guy () alum mit edu> wrote:

> On Jul 19, 2019, at 11:41 AM, phreakocious <phreakocious () gmail com> wrote:
>
> > Hello, as mentioned in the subject, these menu options are disabled in
> the packet list.  My (probably flawed) muscle memory insists that it worked
> at some point.  The other columns work fine so it seems to be intentional.
>
> Never attribute to intent that which can be explained by "whoops, I guess
> that doesn't work, maybe we need to do that differently".  Copy -> As
> Filter in the Protocol column is disabled in a recent master build if
> you've just read in a file, but if I go to the packet details pane, select
> a field, use Copy -> As Filter on that field, and then go back to the
> Protocol column, it's re-enabled - it still doesn't *work*, but it's
> re-enabled.
>
> This code needs some work, both for the enabling and for the "still
> doesn't work".
>
> The former may be due to the filter-related menu actions being "shared"
> between the packet list and packet detail panes, which they probably
> shouldn't be, given that they're *not the same actions* - the packet list
> ones deal with filters for *columns*, the packet details ones deal with
> filters for *fields*.
>
> The latter appears to be due to the fact that we simply don't *set* a
> filter expression for the Protocol column, and may never have done so (so
> your muscle memory may, indeed, be flawed).  That column is currently just
> set as text by dissectors; we'd have to add a separate API for setting the
> protocol column, allowing the column filter to be set, and change the
> dissectors to use that.
>
> >  My gut says it's due to inconsistent/unintuitive behavior in cases like
> an ACK, where filtering by protocol would result in all TCP.
>
> 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".
>
> > This is a bit annoying, but debatably less so than the back and forth
> movement to the details view to filter simpler things like ARP, DHCP,
> (M)DNS, etc.
> > Given that it's probably just as hard to whitelist the simple protocols
> as to blacklist the complex ones, maybe it could just be a global option to
> enable that function for all protocols?
>
> Or maybe it has nothing to do with deliberate disabling for the Protocol
> column, but has to do with
>
>         1) bogosity in the UI code causing the enabled status in the
> packet list pane tracking the enabled status in the packet details pane
>
> and
>
>         2) not having written the necessary mechanisms to add a filter
> expression for the Protocol column (which isn't necessarily the result of a
> deliberate decision that it *shouldn't* support a column filter).
>
> Please file a bug on the "disabled in the packet list" part, so we can get
> that fixed first; that's just a bug.  Then we can file a separate
> enhancement to allow filtering on the Protocol column.
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe