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.
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.