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 <g...@alum.mit.edu> wrote: > On Jul 19, 2019, at 11:41 AM, phreakocious <phreakoci...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
