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] Filtering

Date: Wed, 1 Apr 2009 3:28:21 +0000
hello,

well theres no way i can change how the lib dissects since it is used in many more programs than just wireshark. 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. 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.

Any other ideas? Hopefully you can understand that i would do it differently if i could, but unfortunately this is not the most important project and is only used for troubleshooting the complex protocol in which my company wants to use their already made lib,

Thank you for all the help, it has helped me better understand wireshark dissection,

Greg

Guy Harris wrote:
> On Mar 31, 2009, at 4:22 PM, gogrady@xxxxxxxxx wrote:
>
>> The only way to dissect this protocol is through the dll, i cannot  
>> create it soley in the plugin as is the design requirements.
>
> Can you tell whoever imposed those design requirements that perhaps  
> they should impose *on the DLL* a design requirement that there be  
> ways of getting, for each field, the *raw data* rather than some  
> "helpful" human-readable interpretation of the field - and that it  
> return the raw byte offset and length-in-bytes of a field, if it  
> doesn't do so already -  if they're going to make use of the DLL a  
> requirement for the design of the Wireshark dissector?
>
> Otherwise, it's somewhat like imposing a design requirement on a house  
> that the only form of hammers to be used when building the house are  
> sledgehammers, even for hammering nails into walls.