build errors. First time cmake user

edit

I think I found the new dll's that I added in /run/RelWithDebInfo. But the dll's doesn't seem to dissect when I open the wireshark.exe from this directory. Am I supposed to add these dll's plugins in some other folder? Since in version 1.12.6, there is a wireshark-gtk2 directory where I can test out my dlls. These are the same source code that I ported over from another machine with wireshark version based 1.12.6. which dissects fine with that version, so I am not sure why it did not function in version 2.6. I had to change some prototypes of some functions to upgrade from 1.12.6 to 2.6, but it did build successfully and dlls are generated it seems. Where and how can I test these new dlls? Do you have any idea? thanks

Yes the instructions in 9.2 are required, you must add a CMakeListsCustom.txt with the required path to your custom plugin.

Gryphon has been moved to a built-in dissector, the docs will be updated. Use any other plugin to copy (and modify accordingly) the CMakeLists.txt and plugin.rc.in.

The Wireshark API can and does change between versions, even 2.4 -> 2.6 for instance, so taking code written for 1.12.6 and porting it to 2.6.0 will definitely require changes.

When building a RelWithDebInfo build on Windows, the generated binaries and all supporting files are found in run/RelWithDebInfo. Running Wireshark from that directory will load all the plugins built. If you aren't getting the dissection you expect, then it's likely that you haven't correctly updated the dissector for use with 2.6.0.

Our custom dll is to dissect l2tpv3 frames. It generates the custom dll in the RelWithDebInfo but when open wireshark, it is still dissecting as a default Cisco HDLC frame. Not sure what I'm missing here.Will be looking into this. Was wondering where to add this custom dissector code? Placing in plugins directory did not seem to work. And tried moving under wireshark/plugins/epan doesn't seem to work also. I have a dir path instead of just one file for this custom code.

If the dll appears in the correct place in the RelWithDebInfo directory along with the other plugin dll's, then it is building correctly and it's likely to be code changes in Wireshark that is preventing your plugin from being called.

What does your protocol registration handoff routine look like?

Apparently I was incorrect in a previous comment, Gryphon remains a plugin.

I believe this instruction maybe an issue. This is in proto_reg_handoff

pmi_handle = create_dissector_handle(dissect_pmi, proto_pmi);
dissector_add_uint("ip.proto", l2tpv3_protocol_id, pmi_handle);

I saw in gryphon, it uses dissectoraddunitwithpreference. Does the function dissectoradduint needs to be replaced? thanks in advance.

after I changed the function to dissector_add_uint_with_preference, the dll did not get generated, instead when I launched the wireshark.exe, it gave me this error for several dlls. Some dlls are not mine, but got this message saying Mutiple problems found. The plugin 'usbdump.dll' has no plugin_version symbol. and the same errors for ethercat.dll, grpyhon.dll, etc. including my custom dll.

AFAIK the order of registration isn't guaranteed. Have you tried disabling the built-in dissector via the GUI option Analyze | Enabled Protocols ?

tried disabling ll2tp protocol from GUI Analyze->EnabledProtocols-> unchecked the l2tp, and the frames are decoded as IPv4 frames instead of custom frames. When I disabled, IPv4 (unchecked this box) and the frmaes are shown as generic Protocol 0x0800. I dont know how to enable the custom protocol.

I wasn't sure if disabling also stopped the registration, apparently it doesn't. I think you'll have to disable the built-in dissector in your build. Comment out the file in epan\dissectors\CMakeLists.txt, regenerate the CMake files and rebuild.

was wondering before changing the build-in dissector, whether wireshark can provide a method to choose the frame preference. For example, in GUI, Edit->Preferences->Portocol->Frame->Treat all frames as L2TP? Currently, there's a way to treat all frames ad docsis frames or not with a box (checked or unchecked). Even if there's no GUI, do you know a source code for this view preferences to treat frames as?

The proto_reg_handoff_xxx should look like this:

void
proto_reg_handoff_3146(void)
{
    dissector_handle_t l2tp_3146_handle = create_dissector_handle(dissect_3146, proto_3146);
    dissector_add_uint_with_preference("udp.port", global_3146_request_port, l2tp_3146_handle);
    dissector_add_uint_with_preference("udp.port", global_3146_data_port, l2tp_3146_handle);
}

Can you also show:

1. The signature of the dissect_3146 function
2. The part of your proto_register_xxx function that registers the protocol and preferences.

The dissection function:

static void dissect_3146(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,void* data);

void
proto_register_3146(void)
{
    /* A header field is something you can search/filter on.
     * 
     * We create a structure to register our fields. It consists of an
     * array of hf_register_info structures, each of which are of the format
     * {&(field id), {name, abbrev, type, display, strings, bitmask, blurb, HFILL}}.
     */


    if (proto_3146 == -1) {
        proto_3146 = proto_register_protocol (
            "BCM3146 Protocol", /* name */
            "BCM3146 Req",      /* short name */
            "bcm3146req"        /* abbrev */
            );
    }
}

Here's another one with register

void
proto_register_bdcp(void)
{
    /* A header field is something you can search/filter on.
     *
     * We create a structure to register our fields. It consists of an
     * array of hf_register_info structures, each of which are of the format
     * {&(field id), {name, abbrev, type, display, strings, bitmask, blurb, HFILL}}.
     */


    if (proto_bdcp == -1) {

        proto_bdcp = proto_register_protocol (
                        "BDCP Protocol",        /* name */
                        "BDCP",         /* short name */
                        "bdcp"          /* abbrev */
                        );

        bdcp_dissector_table = register_dissector_table ("bdcp",
                                    "BDCP Protocol",
                                    proto_bdcp,
                                    FT_UINT16, BASE_DEC);
        proto_register_field_array(proto_bdcp, hf, array_length(hf));
        proto_register_subtree_array(ett, array_length(ett));
        proto_register_subtree_array(ettrpcmd, array_length(ettrpcmd));
    }
}

That looks OK apart from the superfluous conditionals around the registration calls. No need for that at all.

The fact that you get errors from the distribution provided plugins concerns me. Until you can get a clean build from the unmodified source code that then runs without errors I think you're on shaky ground.

Yes, not sure because I have windows 10 with 64 bit machine and also had to use a different qt version 5.11 instead of 5.9 per Wireshark instruction. I'm getting these warnings in the build regarding unknown option '/Qspectre' in the distributed code.

"C:\Development\wireshark\wireshark\Wireshark.sln" (default target) (1) ->
"C:\Development\wireshark\wireshark\ALL_BUILD.vcxproj.metaproj" (default target) (2) ->
"C:\Development\wireshark\wireshark\plugins\epan\wimaxasncp\wimaxasncp.vcxproj.metaproj" (default ta
rget) (126) ->
"C:\Development\wireshark\wireshark\plugins\epan\wimaxasncp\wimaxasncp.vcxproj" (default target) (12
7) ->
  cl : Command line warning D9002: ignoring unknown option '/Qspectre' [C:\Development\wireshark\wir
eshark\plugins\epan\wimaxasncp\wimaxasncp.vcxproj]

The QSpectre warnings are because MS has been slow to update VS2015. There has been a recent change to the source to test the flag and only use it if supported.

Qt 5.9 is still available, the online installer gives you the option if you ignore the "Preview" element and expand the "Qt" element.

yes, I tried to download the qt5.9 and got error in installation. That's why I had to use their 5.11 which installed successfully. May try again with qt5.9 later.

FWIW, I currently build with 10.1 with no issues.

yeah, when I added my custom dlls in the downloaded wireshark folder /plugins/2.6/epan and when launch the wireshark, I got the following Multiple problems found. Dont know how to rid of these plugin_version issue.

The plugin 'bdcp.dll' has no "plugin_version" symbol

The plugin 'uepi.dll' has no "plugin_version" symbol

I think that's set by the following lines at the top pf the plugin CMakeLists.txt (from the gryphon plugin):

include(WiresharkPlugin)

# Plugin name and version info (major minor micro extra)
set_module_info(gryphon 0 0 4 0)

What do you have there for your errant plugins?

mine is

include(WiresharkPlugin)

# Plugin name and version info (major minor micro extra)
set_module_info(bdcp 0 0 1 0)

But remember, I am having errors for plugin version not found for gryphon too when launched the wireshark from run->RelWithDebInfo. If I closed the the wireshark problem box, I can still open pcap files to view. But when I launched from downloaded wireshark tool on my pc, I did not see this error for gryphon.dll, but only for my custom dll. This suggests my build environment may have issue with this plugin_version. Not sure how to fix this.

The resource compiler is used to process the rc.in files and as you had issues with the resource compiler (rc.exe) not being on the path and you copied over the files from the Windows kit, I think that might be causing the plugin issue.

I fear you may have to uninstall VS2015, ensure all traces are removed, and then reinstall. I suppose you could try the repair option.

So, I repaired the VS2015 and that fixed the rc.exe and redl.dll issue. But it did not fix the pluginversion issue. So, I removed the QT version and redownload the Qt 5.10. And rebuilt and now after the build and tried to launch the wireshark from RelWithDebInfo and I got wireshark error window saying Entry Point not found. isRightToLeft@QtPrivate@@YANCQStringView@@@Z could not be located in the dynamic link library. C:\Developement\wireshark\wireshark\run\RelWithDebInfo\Qt5 Gui.dll.

Did you delete your build directory and start again with the new VS and Qt? If not, then some old info will likely be cached.

Delete the build directory (not the source) and re-run the CMake generation step and then the build.

If you have correctly added your custom plugins to the build system, then they will be automagically copied to the correct place in the run directory. Having to manually copy them indicates that you haven't correctly added them to the build system.

It's not clear to me, but are you copying the custom dll's from a 1.12.6 build into a 2.6 build? If so, that won't work at all. You must build the plugins for 2.6 by adding the source code to the build.

I really do recommend deleting the build directory and regenerating and building again.