On Sun, 2022-08-21 at 15:53 +0200, Jirka Novak wrote:
> My goal is to prepare library calls (at least for C) which will hide
> details for developer and there will be just callback and/or global flag
> that extcap should finish its work. Extcap author can use it if graceful
> shutdown is required.
I think the mechanism should be as simple as possible, so it is
feasiable to be implemented in whatever language the extcap is written
in.
> 1) Looks limiting to me, because my understanding is that it requires
> that extcap must create hidden window to be able to receive WM_xxx signals.
> I'm afraid it can be limiting/additional complexity for extcaps. I can't
> evaluate whether it has any other consequences for extcap code.
WM_CLOSE probably cannot work at all when the extcap is run via wrapper
script, like .bat files that are needed for Python extcaps.
> 2) It works, but it requires change how command line is parsed, because
> name of named pipe must be passed to extcap. !5489 implements it as new
> pipe even there are control pipes which are already processed by API.
> Patch can be modified in that area.
> Library for C is proposed and it automates cli parsing.
This sounds like a last resort if everything else fails.
> 3) It makes sense to me even I didn't tried it yet. My understanding of
> documentation is that 3) is more preferred in Win32 world.
> I see important that name of event must be agreed between wireshark and
> extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every
> extcap including ones called from different wireshark application. I
> think it should not work this way.
> Name of Event can be new parameter for extcap, but it requires cmd line
> change.
> We can try to derive name of Event from filename/pipe to which extcap
> writes output. It is different value for every wireshark/extcap
> combination. It do not require any changes on command line.
> I found no other dependency for use of Events. It looks promising to me.
I don't like this idea because it requires too much effort on the
extcap side to implement just shutdown (the control pipe atleast could
be extended with other uses).
> Pros of 1) and 3) is that Wireshark do not have to care whether extcap
> supports it. If it does, it will process signal or event. If it doesn't,
> Wireshark can send them and nothing bad happens to wireshark nor extcap.
The 30 seconds timeout will happen every time the user wants to stop
the capture. You could try to workaround that by trying to detect if
extcap handles the graceful shutdown, but that is a workaround.
> On the other hand 2) depends on support on extcap side, but proposed
> library solves it.
You assume every extcap developer will happily use the library, but
there are valid reasons not to: license (extcap does not have to be GPL
compatible) and language.
> 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.
Best Regards,
Tomasz Moń