Wireshark-bugs: [Wireshark-bugs] [Bug 3538] wrong autocomplete with radius.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3538
Bahaa Naamneh <b.naamneh@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |christopher.maynard@xxxxxxxx
| |m, b.naamneh@xxxxxxxxx
--- Comment #3 from Bahaa Naamneh <b.naamneh@xxxxxxxxx> 2009-06-27 03:45:11 PDT ---
Radius dissector uses delayed initializing for its fields, that means, for
optimizing purposes Wireshark will not add the radius' fields to the display
filters tree until one of the fields of this dissector gets a reference. That
explains why you get the full radius fields when you open Wireshark with a file
containing some radius packets.
Regarding how, in spite of that, you got some fields (vendor.*) out there when
you typed radius, that's because those fields do not actually belong to the
Radius dissector; they belong to PacketCable dissector which its developer has
decided to give the PacketCable fields the prefix "radius.vendor.pkt.". And
here we end up again with the same problem I have raised when I wrote the
autocompletion feature. As time goes by, the protocol and field names get more
and more messy and confusing, and that's a problem not for the autocompletion
but also for the users themselves who might be familiar with some protocols and
surprisingly they start seeing some fields not related to the protocol they are
familiar with due to lack of naming rules, as in this case of vendor.* fields
and Radius protocol.
Here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2794 , Chris Maynard
has compiled a list of the questionable display filter field names, according
to the following rules:
1) Any field that is not exactly prefixed with its PROTOABBREV and a period.
2) Any protocol that has zero registered fields.
3) Any field that simply doesn't look similar (stands out) to other fields for
that protocol.
4) Fields with apparent redundancies in their names.
5) PROTABBREV itself is a questionable name, (e.g., it contains a period).
Since this list is too much big, I suggest that one of the core members send a
message and request from the dissector developers which have questionable
display filter field names to review the names and change them according to the
defined rules by Chris. In addition, a script should be written that checks
each dissector for its field's integrity with the rules that have been defined.
Anyway, back to the original problem, I have attached a patch that calls the
function "proto_registrar_get_byname" to force loading the fields of the typed
protocol, if not already done.
P.S. besides to radius dissector, there is only 1 more dissector (wimaxasncp)
that uses fields delayed initializing.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
