Wireshark · Wireshark-dev: Re: [Wireshark-dev] Filtering

["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

I sort of hate to jump back in here because Guy really knows his stuff
and I think he's already given the best advice, but I thought I would
try to provide a more concrete example of what Guy is referring to with
the proto_tree_add_format_value_{something other than text} reference
...

Using the original "time" example, I think the following pseudo-code
should more-or-less do the job:

static int hf_icom_time = -1;

dissect_icom(...) {
    ...
    time = (_GetMsgTime)();
    pi = proto_tree_add_string_format_value(icom_message_tree,
hf_icom_time, tvb, 0, 0, time, "%s", time);
    ...
}

...

    { &hf_icom_time,
        { "Time", "icom.time", FT_STRINGZ, BASE_NONE,
        NULL, 0x00, "", HFILL }
    },
...

- Chris

> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Tuesday, March 31, 2009 11:39 PM
> To: Developer support list for Wireshark
> Cc: Maynard, Chris
> Subject: Re: [Wireshark-dev] Filtering
> 
> 
> On Mar 31, 2009, at 8:28 PM, gogrady@xxxxxxxxx wrote:
> 
> > i am creating a dll interface between wireshark plugin and the
> > protocol lib, it returns the human readable information because that
> > is what is needed for the more important programs that my company is
> > developing.
> 
> That's *all* that's needed?  And they won't make changes to allow the
> DLL to be used conveniently in protocol analyzers as well?
> 
> > There are ways in my dll and lib to get the size of the raw data so
> > that when i highlight in wireshark it highlights the correct bytes
> > in the raw data section, i have functions that i can pass to the
> > proto_tree_add_'s for length that do this, and i have a variable
> > "offset" that keeps track of the current placement in the raw data.
> > The design is and must stay as the raw data is passed plugin ->
> > interface -> lib and then the human readable char * or int from lib
-
> > > interface -> plugin and must be done as so. Unless you have
> > another idea for outputing these types to make filterable, it seems
> > to me that the only way is to use the hidden items along with the
> > add_text.
> 
> The idea that I've already mentioned is that:
> 
> 	for the cases where the library returns an int, if the int value
> is
> the raw data for the field, use it in proto_tree_add_uint() or
> proto_tree_add_int();
> 
> 	for the cases where the library human-readable string, parse the
> human-readable readable string to get the actual value on which you
> want to filter.
> 
> The hidden items won't help here, as, to make them filterable, you'd
> need a value to put into them; if you have that value, you can just
> put it into the regular protocol tree item, using proto_tree_add_
> {something other than text}.  If you want to use the string that the
> library returns as the display string for the item, use
> proto_tree_add_format_{something other than text} or
> proto_tree_add_format_value_{something other than text}, so that the
> protocol tree item has the int value you got from the routine or the
> value you got by parsing the string returned by the library, but is
> displayed with that string.
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and 
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.