I get a linker error when I try to free a subtree using the proto_tree_free() function in my dissector plugin: error LNK2019: unresolved external symbol _proto_tree_free referenced in function _func However I'm able to call other functions declared in epan/proto.h such as proto_item_add_subtree(). Why the linker error? asked 14 Aug '12, 02:40  SidR edited 14 Aug '12, 02:41 showing 5 of 7 show 2 more comments |
One Answer:
On Windows, functions have to be exported from the libwireshark dll so that plugins can use them. The export definitions are listed in epan\libwireshark.def and proto_tree_free isn't in there. Modify the file as required, rebuild libwireshark and you should be good to go. answered 14 Aug '12, 03:56  grahamb ♦ Thank you. Adding the function to libwireshark.def did the trick. (14 Aug '12, 04:02) SidR I've added the function to libwireshark.def and committed to Wireshark trunk in r44485. (14 Aug '12, 04:25) grahamb ♦ It's my understanding that the export definitions listed in (14 Aug '12, 13:40) cmaynard ♦♦ |
Why are you trying to free a protocol tree from within a dissector?
My plugin postdissector dissects certain proprietary suboption fields found under TCP options, they used to be displayed as "Unknown". Currently I'm just hiding the associated text node by changing it to a hidden node, but I wanted to know if it was possible to remove the redundant text node instead, just in case.
So which to which TCP option have you added your proprietary suboptions? Presumably that option has a mechanism to support proprietary suboptions, in which case the Wireshark dissector for that option should be enhanced to allow third-party dissectors to plug into it.
I sorry if I'm misunderstanding your comment. I'm not adding anything to an existing TCP suboption, instead I'm adding a TCP suboption which was previously unidentified(and hence displayed as "Unknown").
A "suboption" is part of an option, otherwise it wouldn't be a "suboption", it'd just be an "option".
So either you're adding a TCP option, not a TCP suboption, as per RFC 793, or there's an existing TCP option that has suboptions, to which you're adding a new suboption.
If it's an option, did you use the RFC 4727 mechanism for them, or did you do them in some other fashion?
If it's a suboption, what's the TCP option to which you're adding it?
My apologies! Thanks for the clarification. I'm adding a TCP option, not a suboption. I'm not adding any suboptions to an existing option either. I'm sorry for the confusion.
Also, I haven't used any of the options reserved for experimentation according to RFC 4727.
OK, then presumably this is only used for TCP sessions between machines running software that you control (and that you can update if the IETF assigns the option number to some other option).
Then the best fix might be to have a mechanism by which a dissector can be registered for a particular TCP option number; that could handle both your case and the "reserved for experimentation" case. File a bug for this at bugs.wireshark.org.