ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Future of extcap "API"

From: Jirka Novak <j.novak@xxxxxxxxxxxx>
Date: Wed, 24 Aug 2022 12:15:20 +0200
Hi,

On Tue, Aug 23, 2022 at 6:24 PM Jirka Novak <j.novak@xxxxxxxxxxxx> wrote:
The problem with GenerateConsoleCtrlEvent() is that the caller has to
be attached to the target process console. While we could technically
do so, it requires freeing any already open console because process
can be attached to at most one console. The pretty much only sane
solution to the problem is to have a helper program between Wireshark
and extcap.

The helper would simply spawn extcap with provided parameters and
accept commands from Wireshark e.g. on pipe. The commands would be to
gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully
terminate (TerminateProcess()). Note that the helper must not be
forcefully terminated as it would leave the extcap running.

While far from ideal, I think the helper is the only sensible
approach. Note that GLib gspawn-win32-helper does something different,
so going back to the GLib helper is not what this is all about.

Even I understand reasons, it looks to me very complex. I'm sorry, but
my Win32 skills are too low to make it.

Nobody says that you have to write it yourself. I understand your
desire to have things available quickly, but I believe this should be
part of the gradual extcap refinement that is ongoing (and led to
seemingly unrelated changes like the leaking handles fixes, GLib event
loop integration and significant mmdbresolve speedup) and not just
slapped together.

Yes, I was looking to "quick" solution as I updated extcap to require graceful shutdown and it is crossplatform. *nix world is solved and I'm working mainly on it, so I can wait with Windows side.
I want to help, if I'm capable of it.

I agree with you, that it makes sense to invest effort to better and scalable solution. Lets focus on it.

There is my view of discussed proposal:

wireshark(1) - something(2) - helper(3) - signals(4) - extcap(5)

(1) Wireshark should be able to start extcap. Wireshark must be able to query for parameters of a extcap and should support control pipes (UI stuff, works nowadays). (2) We are looking for any solution there. It can be pipe as for dumpcap nowadays, but other options are welcomed. (3) helper is responsible for extcap control. On Win32 it should handle console stuff and allows us to use signals between helper and extcap on Win32.
(4) *nix or Win32 console signals are used there
(5) Extcap should be simple and we prefer to use OS specific features - signals for graceful shutdown. Extcap can be written in any language, can be single or multiplatform. Extcap should be modified if and only if it requires graceful shutdown.

Points to discuss:
It the diagram complete?
I'm not sure about dumpcap. There is dumpcap started for every extcap, which reads data from extcap and pass it to wireshark.
Does helper staff involve it?

Helper will help us with solving Win32 stuff. Do we need it just on Windows or on every platform? For *nix it is useless I think, but using same approach on every platform can be useful.

There is negotiation between wireshark and extcap before extcap is started - it provides wireshark with name of extcap, supported interface, required parameters...
I think it would stay as it is. So helper will not be used there.

When extcap prints anything to STDOUT or STDERR, it is passed to Wireshark (there are extcap console works running). STDERR is shown as error/information to a user when extcap is finished. We must pass this thru helper.
How helper's STDOUT/STDERR will be handled?

Extcap can support control pipes. They are passed to extcap as parameters.
I think that control pipes will bypass helper. I mean parameters/names of pipes will be passed thru helper, but helper will not open/close/touch control pipes.

Wireshark is the one who creates command line for extcap - name of binary and its parameters. This information should be passed to helper and it will run command line. How to pass this information to helper? I'm afraid that pass it as command line parameters can create issues - e.g. same parameter name for helper (it needs some) and for extcap, special character escaping, ...
So I propose some other way, but I have no proposal.

How Wireshark will control helper?
We can't use signals on Win32. So pipe or windows events?

What about writing notes/discussed points to a document/wiki?

						Best regards,

							Jirka