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.