When calling proto_register_protocol(), a filter name is required and it has to be unique.
But there is nothing that forces a dissector to add something to the tree.
ethertype is probably the most common example. It's a valid display filter that matches nothing.
Would a hidden field match a display filter and should there be one on dissectors with no tree items?
Trying to determine how to disable a protocol display filter on the back end seems tedious.
Perhaps a new function that a dissector calls to register itself on a list of non-filterable protocols?
Or modify proto_register_protocol to accept a null string for filter name and not process it?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
proto.c
----------
proto_register_protocol(const char *name, const char *short_name,
const char *filter_name)
check_valid_filter_name_or_fail(filter_name);
if (g_hash_table_lookup(proto_filter_names, filter_name)) {
g_error("Duplicate protocol filter_name \"%s\"!"
" This might be caused by an inappropriate plugin or a development error.", filter_name);
}
README.dissector
------------------------------
Only true protocols should be registered as protocols. This is
so that a display filter user interface knows how to distinguish
protocols from fields.
The logical proto_tree needs to know detailed information about the protocols
and fields about which information will be collected from the dissection
routines. By strictly defining (or "typing") the data that can be attached to a
proto tree, searching and filtering becomes possible. This means that for
every protocol and field (which I also call "header fields", since they are
fields in the protocol headers) which might be attached to a tree, some
information is needed.