[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-dev
Subject: [Wireshark-dev] proto_register_protocol() - filter name mandatory
From: chuck c <bubbasnmp () gmail ! com>
Date: 2020-10-26 23:43:47
Message-ID: CAF4O9rSbt-m_mTABRKttW9M3e6SCPf8RVnBYJZETp8UPgGeK3g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
https://gitlab.com/wireshark/wireshark/-/issues/16541
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.
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_default" style="font-size:small"><a \
href="https://gitlab.com/wireshark/wireshark/-/issues/16541">https://gitlab.com/wireshark/wireshark/-/issues/16541</a><br></div><div \
class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">When calling proto_register_protocol(), a filter name is \
required and it has to be unique.</div><div class="gmail_default" \
style="font-size:small">But there is nothing that forces a dissector to add something \
to the tree.</div><div class="gmail_default" style="font-size:small"><br></div><div \
class="gmail_default" style="font-size:small">ethertype is probably the most common \
example. It's a valid display filter that matches nothing.</div><div \
class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">Would a hidden field match a display filter and should there \
be one on dissectors with no tree items?</div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">Trying to determine how to disable a protocol display filter \
on the back end seems tedious.</div><div class="gmail_default" \
style="font-size:small">Perhaps a new function that a dissector calls to register \
itself on a list of non-filterable protocols?</div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">Or modify proto_register_protocol to accept a null string \
for filter name and not process it?</div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br></div><div \
class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">proto.c<br></div><div class="gmail_default" \
style="font-size:small">----------</div><div class="gmail_default" \
style="font-size:small">proto_register_protocol(const char *name, const char \
*short_name,<br> const char *filter_name)<br></div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> \
check_valid_filter_name_or_fail(filter_name);<br><br> if \
(g_hash_table_lookup(proto_filter_names, filter_name)) {<br> g_error("Duplicate \
protocol filter_name \"%s\"!"<br> " This might be caused by an \
inappropriate plugin or a development error.", filter_name);<br> }<br></div><div \
class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">README.dissector<br></div><div class="gmail_default" \
style="font-size:small">------------------------------</div><div \
class="gmail_default" style="font-size:small">Only true protocols should be \
registered as protocols. This is<br>so that a display filter user interface knows how \
to distinguish<br>protocols from fields.<br></div><div class="gmail_default" \
style="font-size:small"><br></div><div class="gmail_default" \
style="font-size:small">The logical proto_tree needs to know detailed information \
about the protocols<br>and fields about which information will be collected from the \
dissection<br>routines. By strictly defining (or "typing") the data that \
can be attached to a<br>proto tree, searching and filtering becomes possible. This \
means that for<br>every protocol and field (which I also call "header \
fields", since they are<br>fields in the protocol headers) which might be \
attached to a tree, some<br>information is needed.<br></div><div \
class="gmail_default" style="font-size:small"><br></div></div>
[Attachment #6 (text/plain)]
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic