Wireshark-dev: Re: [Wireshark-dev] Filtering
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <[email protected]>
Date: Tue, 31 Mar 2009 20:39:17 -0700
On Mar 31, 2009, at 8:28 PM, [email protected] 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.