Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 52341: /trunk/epan/ /trunk/epan/diss
Date: Sat, 5 Oct 2013 20:12:20 -0400 (EDT)
The attached patch implements the "_ws." prefix for "wireshark (internal) protocols".  Taps were (intentionally) left alone. The filters themselves work, but it exposes a bug (?) with the display filter dialog - the intellisense/autocomplete doesn't look for "protocols" after the first period is entered.  Typing "_ws" exposes all of the new (protocol) filters, but when "_ws." is typed, all of the protocols aren't in the list, just the (new) expert filters.  Verified this with other protocols (like gluster.cli) as well.  For something as popular as the "malformed" display filter, the issue should probably be addressed before this patch is applied.
Since filterable expert info is the driving force for creating these "protocols" and it's only available in 1.11, there was no intention of backporting.  I just figured "malformed" was so commonly used, it would be somewhat of a shock to users when it changes.

-----Original Message-----
From: Joerg Mayer <[email protected]>
To: Developer support list for Wireshark <[email protected]>
Sent: Fri, Oct 4, 2013 11:38 am
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 52341: /trunk/epan/ /trunk/epan/dissectors/: packet-usb-video.c /trunk/epan/: expert.h proto.c proto.h

On Fri, Oct 04, 2013 at 10:12:08AM -0400, [email protected] wrote:
> I like the suggestion of a "_ws." prefix, but my hesitation is backwards 
compatibility.  The only "not real" protocol filter I use consistently is 
"malformed" and I like that simplicity.  And the other "protocols" in 
show_exception.c seem reasonable, but like you said, it starts to get ugly for 
some of the "lesser" error cases.  

IMO we should not change the 1.10 code, but I don't mind breaking things
in 1.11 - we are doing that all the time. Of course it needs to be part
of the 1.12/2.0 release notes.

> Should I provide a patch here with your suggestion or log something in 
Bugzilla for people to test?

Both methods are fine with me, maybe a ml post will draw more responses.

Joerg Mayer                                           <[email protected]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
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

Attachment: _ws.protocol.patch
Description: Binary data