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

[Ulf Lamping <ulf.lamping@xxxxxx>]

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