Wireshark · Wireshark-dev: Re: [Wireshark-dev] Cannot get external capture (extcap) interface to work with my new plugin.

[hdv <henri.de.veer@xxxxxxxxx>]

On 2-1-2019 18:30, Dario Lombardo wrote:

You cannot trace your code using prints because they're handled by the caller (dumpcap). Have a look at the other extcaps for --debug and --debug-file options to see how it's solved there.

I only see g_warning/g_error/g_debug messages in the other extcap plugins. There is no descent example that really works from the user perspective. The function g_error is not really useful because it forcefully "breaks" the program. See my original post where I already explained this.

Only extcap_cmdline_debug() does display something in the debug log, when enabled. I see it used g_debug() that ends up in the debug log file. Still a pity that you can't show any popup or error message in a plugin. Or am I missing something?

I really would expect that the stderr channel could be used to report errors in some way. Tested it, does not display anything until you stop the capture. It would be better to display it immediately. You should assume when anybody uses a plugin we can report errors to the user in a sensible matter. The end user should not need to enable debugging or build the code to get errors. I my example I want to report an error to the user when the plugin cannot make a connection to the external device for example.

I have the impression that most extcap plugins need some overhauling of code. Most are very different with respect to some "boilerplate" code everybody uses. So it took me quite some time to cherry pick pieces of the code which looks to be "best practice". Maybe a template/skeletion could be a good idea?

So what is the status of the current extcap plugins, are they still all functional? I can imagine they are harder to test because some are proprietary/need special hardware.

PS: Don't understand me wrong about the above remarks: Wireshark is one of the best documented open source projects I have ever seen in my 25+ years of software experience. Most projects can take it as an example how to document and handle it. So I really want to contribute to it, and even get it better.

Another question off topic: When not a "member" all posts to the wireshark-dev mailing list are moderated so it takes some time to get a post into this list. Who can become member? Is there somewhere described what the procedure is? (I still have some questions and remarks etc. about testing and documentation for example)

Note: I have seen all documentation on the development process. I did not find anything about the mailing list about any membership.

On Wed, Jan 2, 2019, 17:40 hdv <henri.de.veer@xxxxxxxxx wrote:

I actually found the issue(s), there were multiple issues stacked on top of each other:

1) When using parameters and you fill in the default value in the dialog before you start the capture, these parameters are not passed to the extcap plugin. My assumption was that the parameters would always be passed.

This resulted in my plugin in a null pointer for the hostname (one of the parameters called "host" in my case) that needed to be resolved. Unfortunately no program crash occurs or any trap was generated. So it was not seen. I fixed this by copying the default hostname/ip-number before parsing all the command line options in my final parameter structure.

So probably the program was just hanging in some loop/deadlock.

=> This was the main reason that tshark did work because I supplied the --host=192.168.2.51 argument so all went well.

2) The function gethostbyname() does not work on the W8.1 system I have for some strange reason. Even when I fixed the issue with the null hostname I still did not get any resolved hostname (gethostbyname returned an empty list: no error). I had to rewrite the code to use getaddrinfo(), that does the job.

PS: Roland, the flush is already present in the code.

This brings me to some other question: How can I trace my code flow from within the wireshark gui?
I would expect that it will end up in the window that I can open in the left lower corner of wireshark.

It is not clear to me how to do this. I tried some of the g_debug/g_message/g_info calls but it does not end up anywhere or displays a popup or crashes the program with a debugger trap call.

So it took me quite some time to figure out what went wrong because I could not "peek" into the system in a simple way.

Henri

On 30-12-2018 18:18, Roland Knall wrote:

Hi

Have you properly closed the pipe after sending the packets? It looks more like an issue in flushing the pipe, then a code error. tshark handles this a little bit different then wireshark, so that might be the reason, why it did work on the CLI. 

Try flushing the pipe immediately after every packet. Otherwise, without the code nothing much can be said.

kind regards

Roland

---

Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. www.avast.com