Hi all. Due to the numerous tutorials I found in web, I managed to compile a dissector plugin on Linux. The raw implementation of my plugin works fine now. My new goal is to extend the plugin providing an ECDDSA-signature check "on the fly" of the received data packages. Therefore I tried to link my dissector plugin against the crypto library of OpenSSL, but at his point all my efforts unfortunately failed. I didn't find anything in web dealing with such kind of problem so I decided to post this question here. My efforts until now: 1 . I edited Makefile.am in my plugin directory and added the following to the "LIB" line: after that I did configure, make clean and make but the plugin didn't linked against the OpenSSL lib. 2 . I tried to edit Makefile of the plugin but again with no result. There aren't any errors during Compilation, but when I start Wireshark, there is "Couldn't load module error". In addition when i call ldd on .so file of my plugin i can't find crypto-library there. So my guess is it's a linker error, but I have no idea how to solve it. Any help is highly appreciated. Many thx, Arthur EDIT: strangly i can't post a comment below, so I'm writing it here: My plugin compiles and works nice without the ECDSA-stuff I want to add. But I'm not able to link my plugin against the extern OpenSSL library, so I can use its EC(DSA)-functions: http://www.openssl.org/docs/crypto/ecdsa.html. I couldn't find any information on how to link against external libraries in readme.plugins or do I miss something important here? Thx asked 13 Aug '13, 04:54  Arthur Giss edited 13 Aug '13, 08:33 |
One Answer:
After spending further time on my problem I finally linked my dissector to a shared library (in my case the OpenSSL lib). However I'm not very happy with my solution :-/. First I briefly describe how it acutally worked. Instead of adding -lssl and -lcrypto to Makefile.am, I searched the Makefile of my plugin itself for linking possibilities for the SSL lib. There I realized a weird thing: Strangely the library path is added four times to the shell variable $(LDFLAGS). According to this i guessed it might be a libtool issue that I'm not able to link against any shared library. Further investigation on the Makefile reveal $(LDFLAGS) is indeed related to libtool linking process. (If this is trivial for you, I'm sry for explaining it, because I have never dealed with Makefiles or libtool before, but used tools like Eclipse for my purposes.) When I add -lssl and -lcrypto to $(LDFLAGS) my plugin works with openSSL support like a charme :-): but my question is now, what is the "official way" to link against a shared library? In readme.plugins the files which have to be adapted are: AUTHORS, COPYING, ChangeLog, CMakeLists.txt, Makefile.am, Makefile.common, Makefile.nmake, moduleinfo.h, moduleinfo.nmake, plugin.rc.in. But unfortunattely none of these files has an influence on the $(LDFLAGS) variable in the final Makefile of the plugin. Variable &(LIBS) in Makefile.am which is supposed to add additional libraries has absolutely no effect because I can write garbage in that variable with no effect on the building process of my plugin? Maybe it's a wireshark bug? Searching the forum I discovered that other users have similar problems too. E.g.: http://ask.wireshark.org/questions/5152/link-shared-library-for-decoder-with-wireshark-on-linux Thanks for any comments, answers. Arthur answered 03 Sep '13, 07:54 Arthur Giss |
Did you run ./configure --with-ssl ?
Thx for the fast help Anders! I tried it again with ./configure --with-ssl, but still the same error. When running ./configure, I realized that Makefile of my plugin isn't generated, e.g. there is no line saying something like "config.status: creating plugins/profinet/Makefile". Is my problem maybe related with it?
Check readme.plugins in the doc folder to see what files need to be changed to build a plugin.