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.