On Mar 31, 2009, at 4:01 PM, Guy Harris wrote:
> Your *best* bet might be to find a way of dissecting the packet that
> doesn't involve your DLL, given the problems you've been having trying
> to use it in Wireshark (probably because it was never designed for use
> in Wireshark, and so is a bad fit for Wireshark; square pegs fit into
> round holes only with a lot of hard pounding and perhaps some ugly
> noises and damage to peg, hole, or both).
Now, in cases where the DLL returns something useful for Wireshark,
rather than just a human-readable text string - i.e., where it returns
the raw value from the packet - you could use proto_tree_add_uint() to
add the value to the protocol tree; that would make it filterable, and
Wireshark would display it for you.
If you're really ambitious, in cases such as
time = (_GetMsgTime)();
pi = proto_tree_add_text(icom_message_tree, tvb, 0, 0, "Time: %s",
time);
you could try parsing the string you get back from the DLL and convert
it to a value that you could hand to a proto_tree_add routine.
If the DLL doesn't hand you the raw offset in the packet data for a
field, or the raw length of the data for the field, you still wouldn't
be able to pass the real offset and length fields to the
proto_tree_add routines, so you still wouldn't be able to click on the
field and see which particular bytes in the packet correspond to the
field (as per my earlier mail), but you might be able to at least work
around some of the DLL's deficiencies.
(Who designed that DLL, and what did they design it for?)
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
