Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Related Information (again)

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Sun, 24 Sep 2006 01:05:09 +0200
Graeme Lunt wrote:
Hi,

Attached is a new version of the related information functionality I had
previously submitted (back in May).
I thought I would ask for comments before checking it in this time! 8^)
:-)
It adds a new menu item "Related Information" and provides a generic
mechanism to register related information for:
* a specific hf_index - register_related_hfid_callback()
* a range of hf_indexes (e.g. "owned" by a given dissector) -
register_related_range_callback() and * a type e.g. FT_OID - register_related_type_callback();
Will this be called for all appearances of a specific type regardless of the dissector / protocol?

In this case it's probably rather useless for most types, so using the hf_index based registration might work better.
In addition, a new FI_URL flag has been defined to mark a field as a URL,
together associated macros - e.g. PROTO_ITEM_SET_URL().
I guess this will present the field in the protocol details tree as a link (similar to "go to frame" fields) to open it in a browser? Sounds reasonable.
This patch shows three different "related information" handlers:
(use the x509-with-logo.cap example capture (packet 2 - Handshake Protocol:
Certificate) to view these)

URL:
The logotypeURI_item has been marked as FI_URL and can be opened in a
browser (e.g. showing the logo)
The uniformResourceIdentifier in a GeneralName has been marked as a FI_URL
(e.g. can be used to download the CRL from the CRLDP)
Please give a more general example, I (and probably a lot of other developers) don't know CRL and CRLDP :-)
OID:
All fields of type FT_OID can bring up the Harald Alvestrand web page (e.g.
certificatePolicies 2.5.29.32).
The actual template URL can be configured on the BER preferences page (may
be moved later). It is a text field (rather than option menu) for those with
no Internet connection, or prefer the elibel site.
Will this be the right way to go for *every* FT_OID field for *every* protocol using it? I have serious doubts here.

And showing a "Harald Alvestrand page" for completely unrelated topics would be very confusing.

I get the feeling that registering related information based on the hf_ might be a better way to go - dropping the field type registration completely.
ASN.1 Modules:
Fields of type "x509.*" can be referenced in the associated ASN.1 module
(usually on the ITU web site) - (e.g. certificate "validity"). Again,
configuration is a text field for those with no Internet connection. All asn2wrs generated dissectors that use modules hosted on the ITU site can
use this mechanism.

[NOTE: This patch changes prefs.c as it does not allow a '#' character in a
preference value (it treats everything after the '#' as a comment). Some of
the template URLs that are used in the above contain a '#' character. Is
there a reason for this behaviour in prefs.c?]
Well, obviously yes, namely to enable comments in the prefs file :-)

I don't know if changing this to start comments only if using the '#' as the first non white-space char in a line would break something.

You might check the whole prefs file for this condition. BTW: if other config files using the same code, they should be checked too.
At the moment, only a single related page can be brought up, but I have
played with a dialog for if/when there are multiple hits.
This might be added on demand later. IMHO having a dialog might not be very user friendly.
Other people should be able to add further related information for their
fields using this mechanism.
That sounds good.
Hopefully this is a cleaner and more acceptable mechanism than last time. If it is, I will check it in.

Comments?
If you send patch files, be sure to:
- diff from the latest SVN version
- (manually) remove unrelated changes, e.g. config.nmake



Conclusion:
This sounds like a much more generic way to display relevant information and I appreciate your work on this.

However: there is a serious usability drawback in this solution.
This works perfectly for the developer of this solution and a user working with the protocol on a day to day basis. Problem: How does an unexperienced user will know at which field related information is available???

"Unexperienced user" scenario:
1. select a field in the tree
2. right click to look if relevant information is available
3. start with 1 until no more fields available
... as you cannot remember thousands of different fields!

As you (hopefully :-) see this isn't really the way to go.

Wouldn't it be a better user experience to simply add the related information as additional generated fields to the packet details tree? Would this add too much new fields?

I've started to do something like this for the MS-DCOM dissector and carefully added this works like a charm :-)

Regards, ULFL