Hi,
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.
Even I understand reasons, it looks to me very complex. I'm sorry, but
my Win32 skills are too low to make it.
The proposal described above combines two approaches - windows signals
and windows pipe.
What I see as missing in discussion is that even extcap will receive
"just" windows signal, extcap must be adapted to handle graceful
shutdown. And sequence will be:
wireshark - pipe - helper - signal - extcap
and to achieve it, we have to modify wireshark, write helper and modify
extcap.
Extcap have to be adapted only if it requires graceful shutdown. But if
it requires it, it must be adapted. If it will not be adapted (do not
require graceful shutdown), it will be terminated as nowadays.
Won't be easier to say, that when author have to modify extcap, they
will use the pipe?
Yes, it is a little more work on extcap side, but it must be touched
anyway. With pipe we will save a lot of effort on wireshark/helper and
complexity of overall solution will be much lower.
Proposal with pipe I made is backward compatible so when extcap is not
modified to support graceful shutdown, it do not expose support of pipe.
Therefore wereshark do not create pipe, do not pass it to extcap and
terminate it as before.
One more note...
*nix world use signals and graceful shutdown is already implemented on
wireshark side. When extcap needs graceful shutdown, it should be
modified to process SIGTERM.
If the extcap should work on Windows too, extcap must support Windows
signals CTRL_BREAK_EVENT in addition to SIGTERM. The code is similar,
but there are differences so code must support two ways how to stop it.
If we will use pipe, it can be used on *nix and Windows world same way
(except #ifdef to use correct API calls). Isn't it better?
I imagine that wireshark will work in that case this ways:
When shutdown of extcap is requested:
1) If pipe is supported, ask extcap for graceful shutdown. When timer
expires, kill/terminate extcap.
2) If pipe is not supported, kill/terminate extcap immediately.
Best regards,
Jirka Novak
