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

From: Roland Knall <rknall@xxxxxxxxx>
Date: Tue, 23 Aug 2022 10:55:47 +0200
Adding another helper may be helpful, as it would probably gives us greater control, and maybe also solve the "helper-script" issue in the future by putting that stuff inside Wireshark? I am just wondering if it is worth the effort. We can obviously strive for a perfect - no user interaction required - solution, but do we really need to be perfect here?

In my experience, as long as we can solve the real issue - the zombie processes - and have minimal interaction by the creators of the original extcaps we should be fine. Now as I understand it, we can achieve that at some level with one of the proposed solutions above, just not in an ideal way, right?

I am fine with having developers adapt their script, as long as there is some form of compatibility mode, and maybe some warning displayed before starting a non-converted extcap

kind regards
Roland


Am Di., 23. Aug. 2022 um 10:38 Uhr schrieb Tomasz Moń <desowin@xxxxxxxxx>:
On Mon, Aug 22, 2022 at 9:37 PM Jirka Novak <j.novak@xxxxxxxxxxxx> wrote:
> >> What do you think about that options?
> >
> > I have no idea why you didn't even consider sending CTRL_BREAK_EVENT
> > using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on
> > Windows. Wireshark creates all extcaps with a hidden console window
> > (CREATE_NEW_CONSOLE and SW_HIDE flags set).
> >
> > CTRL_BREAK_EVENT is really simple to handle on extcap side, as it only
> > requires calling SetConsoleCtrlHandler() to register a handler. The
> > handler will be called in separate thread (unlike UNIX signals), but
> > the issues related to the separate thread are exactly the same in any
> > of the three methods you proposed. Registering handler is really an
> > opt-in, as the default handler simply terminates the process.
>
> I'm sorry, my understanding was it is in !2063. I was wrong, I will try it.

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.

Best Regards,
Tomasz Moń
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe