Wireshark-dev: Re: [Wireshark-dev] Cannot get external capture (extcap) interface to work with
From: hdv <[email protected]>
Date: Fri, 4 Jan 2019 07:04:23 +0100

Please also see my remarks inline too below this about the mailing list and template/example code.

I have some additional information on the errorhandling and what goes wrong in this case:

What I want to do is (when simulating an error in the plugin):

-open the output pipe
-issue a g_error("%s: Could not connect to AnaGate CAN \n", __func__);
-close the output pipe
-return with EXIT_FAILURE

Now the process nicely stops but not "Dumpcap", note that nothing was sent to the pipe at all! The Wireshark gui displays no error at all, only "<live capture in progress>", "No Packets". Stopping the capture shows no error, it just returns to the main screen.

I could recollect vaguely that I have seen an issue with a deadlock in that area the mailing list. So looking it up reveals this:

https://www.wireshark.org/lists/wireshark-commits/201808/msg00263.html,  and I see that I don't have it in my code tree.

Any idea if it is related to this issue?


On 4-1-2019 00:10, Dario Lombardo wrote:

On Thu, Jan 3, 2019 at 5:36 PM hdv <[email protected]> wrote:

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?

No you are not. This is a step missing in the original extcap code (wireshark side). However lately a new support for extcap toolbars has been added. This allows a live message passing between the gui and the extcap. Unfortunately it is not as straightforward as the main text interface and requires a reactor (or similar) to handle the messages, but if you take a look at extcap_example.py you'll get an idea. In C I haven't seen any working implementation of the toolbars: it can work for sure but the work required compared to python is much more.

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?

I'm not sure I've got your point. Which overhauling are you referring to and which boilerplate or best practice code are you talking about? Can you point to some examples? 
A template is somewhat impossible to write: the best we did was to have some base functions (extcap-base) and some working examples for them.
I have seen them and I also use these calls, just forget it for now to avoid cluttering this topic. I will come back on this later.

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.

They're expected to be. If they are not, feel free to open bugs on bugzilla. Extcaps in the source tree except ciscodump don't require special hardware at all.

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.

It has been a loooong time since I subscribed and I don't recall how I did it. But googling I found this: https://www.wireshark.org/mailman/listinfo/wireshark-dev. Did you try it? 

Yes I did that: about half a year ago, to look how the communication between all developers passes by.  What is the criteria to moderate sent emails to the sent wireshark-dev list?

Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Virusvrij. www.avast.com