Greetings, I created a dissector that loads a dll to assist in parsing bytes for display in Wireshark 2.0 using CMake and Visual Studio 2013. The testing piece of the instructions is successful for running the built Wireshark.exe when opening a PCAP files with the necessary packets to test the dissector that imports the dll. I am very clear on how to include the dissector as a plugin on the built installer. But, I am having a problem making sure the imported dll is available for the dissector at deployment. I notice that, at test time, the dll, which sits alongside Wireshark.exe in the build directory, is one level from the plugins directory in order to prevent Wireshark to think it's another dissector with no symbol. Once installed, the plugins directory is two levels from where Wireshark.exe is located since all plugins are placed in a "2.0.0-EXTRA] sub-directory. I would like to know what is best practice for deploying such plugin. Thanks in advanced. asked 18 Dec '15, 14:12  coloncm |
2 Answers:
Well, I managed to deploy the helper dll unto the Wireshark installation directory via an entry in the "Installation execution commands" section of the wireshark.nsi file in the ../wireshark/packaging/nsis directory as below: In my dissector plugin code, I first check if the dll is located one level from the plugin in order to support debugging of the build and, if not, check its location two levels down from the plugin directory in case Wireshark was executed from an installation directory. If neither loads it (null pointer), I simply post text stating it's not available. Not pretty, but works. answered 22 Dec '15, 07:31 coloncm |
The plugins for a build are in a single directory "plugins" underneath the Wireshark executable location, when installed there is an additional directory layer for the version number of the build. There's nothing set up in the CMake build to copy helper DLLs into the build plugins directory from wherever the helper plugins reside so you'll have to do that yourself. Probably best to put your helper DLL in the wireshark-xxx-libs directory where all the other third party DLLs live, and copy it in your plugin CMakeLists.txt in a similar manner to the other third party DLLs in the main CMakeLists.txt. The installer copies the standard DLLs from the build plugins directory into the installed plugins\${VERSION}. This is in packaging\nsis\wireshark.nsi. To add additional plugin DLLs to the install, edit packaging\nsis\custom_plugins.txt to list the additional plugin and any helper DLLs to install. Ideally we should have a way to do this with an additional "custom" file rather than editing one that's under version control. answered 18 Dec '15, 16:20  grahamb ♦ |
I'm glad that your recommendations match my choice of approach. I guess I would have to set the path to the helper dll differently at deployment vs build, i.e., "..\dll" vs "..\..\dll". Is there a way to make that distinction in code, perhaps, via a variable or something?
It's unclear to me why you need to be aware of the path to the helper DLL. AFAICT, it will always be in the same directory as your plugin.
If I keep it in the same directory, Wireshark appears to think it's also a dissector and gives off an error message at startup that "the plugin helper.dll has no version symbol" though works as expected by ignoring the helper dll that's sitting alongside other dissector plugins. I'd rather avoid this. My only recourse is to include the helper dll in the root directory as Wireshark.exe at deployment and let the plugin know to go two directories down (instead of one in the build directory of the solution for debugging) to locate and load it.
Thanks for the info, I understand the issue.
The CMake system (nor NSIS) isn't set-up to handle that at the moment. Please raise an enhancement request on the Wireshark Bugzilla, or even better submit a change when you have it worked out.